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

三層架構

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

圖片

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

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

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

MVC 架構的弊端

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

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

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

圖片

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

Manager 層的特征

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

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

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

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

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

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

Manager 層使用案例

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

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

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

圖片

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

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

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

傳統(tǒng)三層架構代碼示例

@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("員工不存在");
    }
    // 操作數(shù)據(jù)庫 4
    Long departmentSort = departmentEntity.getSort();
    departmentEntity.setSort(swapEntity.getSort());
    departmentDao.updateById(departmentEntity);
    swapEntity.setSort(departmentSort);
    departmentDao.updateById(swapEntity);
    return Result.OK("success");
}

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

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

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

引入 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("員工不存在");
    }
    // 操作數(shù)據(jù)庫 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 層之后，我們將數(shù)據(jù)準備工作放在 Service 層，然后將數(shù)據(jù)傳遞給 Manager 層。Manager 層添加 @Transactional 事務注解，負責進行數(shù)據(jù)庫操作。這樣一來，就避免了長事務問題，提高了系統(tǒng)的性能和可維護性。

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