前言

在 Java 后端開發(fā)中，采用經(jīng)典的三層架構(gòu)（Controller - Service - DAO/Mapper）是業(yè)界廣泛接受的工程實踐。這種分層結(jié)構(gòu)通過職責分離，提升了代碼的可維護性、可測試性和可擴展性。

然而，在實際開發(fā)過程中，一個常見且關(guān)鍵的設(shè)計問題常常困擾開發(fā)者：

在 Service 層中，當需要訪問其他模塊的數(shù)據(jù)或功能時，應(yīng)該注入對應(yīng)的 Mapper（或 Repository/DAO），還是注入另一個 Service？

這個問題看似簡單，但其背后涉及架構(gòu)設(shè)計原則、職責邊界劃分、事務(wù)管理、代碼復(fù)用性與系統(tǒng)耦合度等多個維度的考量。

一、三層架構(gòu)回顧：職責與邊界

在典型的基于 Spring Boot + MyBatis 的 Java Web 應(yīng)用中，三層架構(gòu)的職責如下：

關(guān)鍵原則：每一層只應(yīng)與其直接下層交互，避免跨層調(diào)用（如 Controller 直接調(diào)用 Mapper）。

二、Service 層的依賴注入選項

當一個 Service（例如 OrderService）需要訪問其他實體（如用戶、商品、庫存）的數(shù)據(jù)或行為時，它有兩種主要的依賴注入選擇：

1. 注入目標實體的 Mapper（如 UserMapper）
2. 注入目標實體的 Service（如 UserService）

這兩種方式在語法上均可行，但其適用場景和設(shè)計含義截然不同。

三、何時注入 Mapper？—— 數(shù)據(jù)訪問的直接路徑

適用場景

當你僅需讀取或?qū)懭朐紨?shù)據(jù)，且不涉及目標模塊的業(yè)務(wù)規(guī)則、校驗、事務(wù)或副作用時，應(yīng)直接注入對應(yīng)的 Mapper。

示例場景

• 查詢用戶基本信息用于訂單創(chuàng)建；
• 更新商品瀏覽次數(shù)；
• 記錄操作日志到日志表；
• 批量插入中間表關(guān)聯(lián)數(shù)據(jù)。

優(yōu)勢

• 職責清晰：Service 只負責自己的業(yè)務(wù)邏輯，數(shù)據(jù)訪問委托給 Mapper。
• 性能高效：避免不必要的方法調(diào)用棧和代理開銷。
• 低耦合：不依賴其他 Service 的實現(xiàn)細節(jié)，僅依賴數(shù)據(jù)結(jié)構(gòu)。
• 易于測試：Mock Mapper 即可完成單元測試，無需啟動整個 Service 上下文。

代碼示例

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private UserMapper userMapper; // 直接注入，僅用于查詢用戶是否存在

    public void createOrder(CreateOrderDTO dto) {
        // 僅驗證用戶是否存在，無復(fù)雜業(yè)務(wù)邏輯
        User user = userMapper.selectById(dto.getUserId());
        if (user == null) {
            throw new BusinessException("用戶不存在");
        }

        Order order = new Order();
        order.setUserId(dto.getUserId());
        order.setProductId(dto.getProductId());
        orderMapper.insert(order);
    }
}

注意：此處 userMapper.selectById() 僅返回數(shù)據(jù)，不包含“激活用戶”、“檢查黑名單”等業(yè)務(wù)邏輯。

四、何時注入其他 Service？—— 復(fù)用完整業(yè)務(wù)邏輯

適用場景

當你需要復(fù)用目標模塊封裝好的完整業(yè)務(wù)行為，包括但不限于：

• 數(shù)據(jù)校驗（如用戶狀態(tài)是否有效）；
• 事務(wù)控制（如庫存扣減需回滾）；
• 副作用處理（如發(fā)送通知、記錄審計日志）；
• 狀態(tài)機變更（如訂單狀態(tài)流轉(zhuǎn)）；
• 權(quán)限或安全檢查。

此時，應(yīng)注入對應(yīng)的 Service，而非直接操作其 Mapper。

示例場景

• 創(chuàng)建訂單時需扣減庫存（庫存服務(wù)包含超賣檢查、事務(wù)、日志）；
• 用戶注冊時需發(fā)送歡迎郵件（郵件服務(wù)封裝了模板、重試、異步）；
• 支付成功后需更新會員等級（等級計算涉及多張表和規(guī)則引擎）。

優(yōu)勢

• 邏輯復(fù)用：避免重復(fù)實現(xiàn)相同業(yè)務(wù)規(guī)則，符合 DRY（Don’t Repeat Yourself）原則；
• 一致性保障：所有入口都走同一套業(yè)務(wù)流程，確保系統(tǒng)狀態(tài)一致；
• 可維護性高：業(yè)務(wù)規(guī)則變更只需修改一處。

注意事項

• 避免循環(huán)依賴：A Service 注入 B，B 又注入 A，會導致 Spring 啟動失敗或運行時異常；
• 事務(wù)傳播行為：需明確 @Transactional 的傳播機制（如 REQUIRED vs REQUIRES_NEW）；
• 代理調(diào)用限制：在同一個類中通過 this.otherMethod() 調(diào)用帶事務(wù)的方法會繞過 Spring 代理，應(yīng)通過注入的 Bean 調(diào)用。

代碼示例

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private InventoryService inventoryService; // 注入 Service，因需完整業(yè)務(wù)邏輯

    @Transactional
    public void createOrder(CreateOrderDTO dto) {
        // 檢查用戶（可直接用 Mapper）
        User user = userMapper.selectById(dto.getUserId());
        if (user == null) throw new BusinessException("用戶不存在");

        // 扣減庫存 —— 必須通過 Service，因其包含：
        // - 庫存充足性檢查
        // - 樂觀鎖更新
        // - 庫存流水記錄
        // - 可能觸發(fā)補貨通知
        inventoryService.deductStock(dto.getProductId(), dto.getQuantity());

        // 創(chuàng)建訂單
        Order order = new Order(dto.getUserId(), dto.getProductId(), dto.getQuantity());
        orderMapper.insert(order);
    }
}

五、錯誤實踐與反模式

反模式 1：為了“解耦”而強行通過 Service 訪問簡單數(shù)據(jù)

// 錯誤示例：UserService.getUserById() 僅返回 userMapper.selectById(id)
User user = userService.getUserById(userId); // 無必要！

問題：增加調(diào)用鏈深度，引入無意義的 Service 層包裝，降低性能，且若未來 UserService 添加了權(quán)限校驗，可能意外破壞 OrderService 的邏輯。

反模式 2：在 Service 中直接操作其他模塊的 Mapper，卻忽略了業(yè)務(wù)規(guī)則

// 危險示例：直接更新用戶余額
userMapper.updateBalance(userId, newBalance); // 繞過了資金變動審計、風控等邏輯

后果：系統(tǒng)出現(xiàn)“幽靈資金變動”，審計日志缺失，違反金融合規(guī)要求。

反模式 3：Service 內(nèi)部通過 this 調(diào)用自身帶事務(wù)的方法

@Service
public class OrderService {
    public void methodA() {
        this.methodB(); // ? 不會觸發(fā) @Transactional
    }

    @Transactional
    public void methodB() { ... }
}

正確做法：通過 self-injection 或重構(gòu)為兩個 Service。

六、決策流程圖：如何選擇？

七、高級考量：領(lǐng)域驅(qū)動設(shè)計（DDD）視角

在更復(fù)雜的系統(tǒng)中，可引入 領(lǐng)域驅(qū)動設(shè)計（DDD） 思想進一步指導分層：

• 聚合根（Aggregate Root）：只有聚合根的 Repository 可被外部 Service 直接調(diào)用；
• 領(lǐng)域服務(wù)（Domain Service）：跨聚合的業(yè)務(wù)邏輯應(yīng)封裝在領(lǐng)域服務(wù)中；
• 應(yīng)用服務(wù)（Application Service）：即傳統(tǒng) Service 層，協(xié)調(diào)領(lǐng)域?qū)ο蠛突A(chǔ)設(shè)施。

在此模型下，跨聚合的數(shù)據(jù)訪問必須通過領(lǐng)域服務(wù)或聚合根方法，禁止直接操作其他聚合的 Mapper。

雖然本文聚焦于傳統(tǒng)三層架構(gòu)，但 DDD 提供了更高階的解耦思路，值得進階開發(fā)者參考。

八、總結(jié)

Service 層應(yīng)優(yōu)先注入 Mapper 來訪問數(shù)據(jù)；僅當需要復(fù)用其他模塊的完整業(yè)務(wù)邏輯時，才注入其他 Service。

具體判斷標準如下：

以上就是Java后端開發(fā)中Service層依賴注入的最佳實踐的詳細內(nèi)容，更多關(guān)于Java Service層依賴注入的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論