初入編程世界時，前輩們總會教導我們，系統設計應遵循 MVC（Model - View - Controller） 架構。MVC 架構就像一個精巧的齒輪組，將整個系統清晰地劃分為 Model（模型）、View（視圖）和 Controller（控制器）三個層次。它巧妙地把用戶視圖和業務處理隔離開來，再通過控制器將它們緊密連接，如同搭建起一座溝通的橋梁，實現了表現與邏輯的完美解耦，是軟件分層架構中的經典范式。

三層架構

MVC 分層架構是架構領域中最為基礎和簡單的分層方式。當我們依據這種架構構建項目時，通常會創建三個關鍵目錄：controller、service 和 dao，它們分別對應著表現層、邏輯層和數據訪問層。

圖片

下面，我們來詳細了解一下每層的具體作用：

• Controller 層：它就像是交通樞紐的指揮者，主要負責對訪問請求進行轉發。同時，它還承擔著各類基本參數的校驗工作，對于一些無需復用的簡單業務，也可以在這里直接處理。
• Service 層：這是業務邏輯處理的核心地帶，如同一位技藝精湛的工匠，精心雕琢著每一個業務流程。同時，它還負責管理事務，確保數據的一致性和完整性。
• Dao 層：它是與底層數據庫（如 MySQL、Oracle 等）進行數據交互的橋梁，負責將業務邏輯層的請求轉化為數據庫操作，為系統提供穩定的數據支持。

然而，隨著業務的不斷發展和代碼量的持續增加，這種看似簡單明了的三層架構逐漸暴露出一些問題。

MVC 架構的弊端

傳統的 MVC 分層架構存在以下幾個較為明顯的問題：

1. Service 層代碼臃腫：隨著業務邏輯的日益復雜，Service 層需要處理的任務越來越多，代碼量不斷膨脹，在此，我想給大家送個福利，關注工眾號：碼猿技術專欄，回復關鍵詞：1111 即可獲取阿里內部 Java 性能優化手冊。導致代碼的可讀性和可維護性急劇下降。
2. Service 層事務問題頻發：在 Service 層，大事務和事務嵌套的情況時有發生。這些問題不僅會導致系統性能下降，還會使問題的排查變得異常困難，給開發和維護工作帶來巨大挑戰。
3. Dao 層業務邏輯混雜：Dao 層原本應該專注于數據訪問，但在實際開發中，往往會摻雜一些業務邏輯，這使得代碼的職責不夠清晰，增加了代碼的耦合度。
4. Dao 層 SQL 語句復雜：隨著業務的發展，Dao 層的 SQL 語句變得越來越復雜，關聯查詢大量增加。這不僅會影響數據庫的性能，還會增加代碼的維護難度。

為了解決這些問題，我們可以參考《alibaba java 開發手冊》，在 Service 層之下新增一個通用業務處理層——Manager 層。

圖片

在這個新的分層架構中，Manager 層與 Service 層相互協作，各司其職。Manager 層提供原子性的服務接口，就像一個個標準化的零件；而 Service 層則根據業務邏輯的需求，對這些原子接口進行編排組合，構建出完整的業務流程。

Manager 層的特征

《alibaba java 開發手冊》對 Manager 層有如下描述：

Manager 層作為通用業務處理層，具有以下顯著特征：

1. 第三方平臺封裝層：負責對第三方平臺的接口進行封裝，對返回結果進行預處理，并將異常信息進行轉化，以適配上層接口的需求。
2. Service 層通用能力下沉：將 Service 層的一些通用能力下沉到 Manager 層，如緩存方案的實現、中間件的通用處理等，提高代碼的復用性和可維護性。
3. DAO 層組合復用：與 DAO 層進行交互，對多個 DAO 進行組合復用，實現復雜業務的數據訪問需求。

在實際開發中，我們可以按照以下方式使用 Manager 層：

1. 復雜業務處理：對于復雜的業務場景，Service 層負責準備好所需的數據，并將其傳遞給 Manager 層。Manager 層負責業務的編排和事務的處理，并且不允許相互調用，避免出現事務嵌套的問題。
2. 通用業務 DAO 封裝：Manager 層專注于編寫不包含業務邏輯的 SQL 語言，對通用業務進行 DAO 層的封裝，提高代碼的復用性和可維護性。
3. 復雜查詢拆分：為了避免復雜的 join 查詢對數據庫造成過大壓力，我們可以在 Manager 層對復雜查詢進行拆分，將其轉化為多個簡單的查詢，減輕數據庫的負擔。

需要注意的是，對于簡單的業務場景，我們可以不使用 Manager 層，以免增加系統的復雜度。

Manager 層使用案例

下面，我們通過一個具體的例子來說明 Manager 層的使用場景。

假設我們有一個用戶系統，其中有一個獲取用戶信息的接口。在傳統的三層架構中，該接口調用邏輯 Service 層的 getUser 方法，getUser 方法再與 User DB 交互獲取數據，具體流程如左圖所示。

這時，產品提出了一個新的需求：在 APP 中展示用戶信息時，如果用戶不存在，需要自動為用戶創建一個新用戶。同時，HTML5 頁面需要保留之前的邏輯，即不需要創建用戶。

圖片

在傳統的三層架構下，邏輯層的邊界變得模糊不清，表現層也不得不承擔一部分業務邏輯。我們通常會在表現層 Controller 中添加業務邏輯處理代碼，將獲取用戶和創建用戶的接口進行編排。

而引入 Manager 層之后，情況就大不一樣了。Manager 層提供創建用戶和獲取用戶信息的接口，就像提供了兩個獨立的工具；Service 層則負責將這兩個接口進行組裝，構建出完整的業務流程。這樣一來，原本分散在表現層的業務邏輯就被統一到了 Service 層，每一層的職責更加清晰明確。

接下來，我們通過一段實際代碼來看看 Service 層與 Manager 層是如何區分的。

傳統三層架構代碼示例

@Transactional(rollbackFor = Throwable.class)
public Result<String> upOrDown(Long departmentId, Long swapId) {
    // 驗證 1
    DepartmentEntity departmentEntity = departmentDao.selectById(departmentId);
    if (departmentEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗證 2
    DepartmentEntity swapEntity = departmentDao.selectById(swapId);
    if (swapEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗證 3
    Long count = employeeDao.countByDepartmentId(departmentId);
    if (count != null && count > 0) {
        return Result.error("員工不存在");
    }
    // 操作數據庫 4
    Long departmentSort = departmentEntity.getSort();
    departmentEntity.setSort(swapEntity.getSort());
    departmentDao.updateById(departmentEntity);
    swapEntity.setSort(departmentSort);
    departmentDao.updateById(swapEntity);
    return Result.OK("success");
}

這段代碼在傳統的三層架構中很常見，但它存在一個明顯的問題——長事務問題（類似的情況還包括調用第三方接口）。在這段代碼中，前三步的驗證操作都使用了同一個數據庫連接 connection。由于方法上添加了 @Transactional 注解，整個驗證過程會一直占用該連接，占用時間可能會很長，直到方法執行結束，連接才會被歸還給數據庫連接池。

對于復雜業務來說，這種長時間占用同一個數據庫連接的做法并不是一個好的選擇。我們應該盡量縮短連接的占用時間，提高系統的性能和并發處理能力。

說明：對于@Transactional 注解，當 spring 遇到該注解時，會自動從數據庫連接池中獲取 connection，并開啟事務然后綁定到 ThreadLocal 上，如果業務并沒有進入到最終的 操作數據庫環節，那么就沒有必要獲取連接并開啟事務，應該直接將 connection 返回給數據庫連接池，供其他使用。

引入 Manager 層后的代碼示例

// DepartmentService.java
public Result<String> upOrDown(Long departmentId, Long swapId) {
    // 驗證 1
    DepartmentEntity departmentEntity = departmentDao.selectById(departmentId);
    if (departmentEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗證 2
    DepartmentEntity swapEntity = departmentDao.selectById(swapId);
    if (swapEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗證 3
    Long count = employeeDao.countByDepartmentId(departmentId);
    if (count != null && count > 0) {
        return Result.error("員工不存在");
    }
    // 操作數據庫 4
    departmentManager.upOrDown(departmentEntity, swapEntity);
    return Result.OK("success");
}

// DepartmentManager.java
@Transactional(rollbackFor = Throwable.class)
public void upOrDown(DepartmentEntity departmentEntity, DepartmentEntity swapEntity) {
    Long departmentSort = departmentEntity.getSort();
    departmentEntity.setSort(swapEntity.getSort());
    departmentDao.updateById(departmentEntity);
    swapEntity.setSort(departmentSort);
    departmentDao.updateById(swapEntity);
}

在引入 Manager 層之后，我們將數據準備工作放在 Service 層，然后將數據傳遞給 Manager 層。Manager 層添加 @Transactional 事務注解，負責進行數據庫操作。這樣一來，就避免了長事務問題，提高了系統的性能和可維護性。

通過以上的分析和示例，我們可以看到，引入 Manager 層可以有效地解決傳統 MVC 三層架構中存在的問題，使系統的架構更加清晰、合理，提高系統的可維護性和性能。希望本文對大家在系統架構設計方面有所幫助。