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

三層架構(gòu)

MVC 分層架構(gòu)是架構(gòu)領(lǐng)域中最為基礎(chǔ)和簡(jiǎn)單的分層方式。當(dāng)我們依據(jù)這種架構(gòu)構(gòu)建項(xiàng)目時(shí)，通常會(huì)創(chuàng)建三個(gè)關(guān)鍵目錄：controller、service 和 dao，它們分別對(duì)應(yīng)著表現(xiàn)層、邏輯層和數(shù)據(jù)訪問(wèn)層。

圖片

下面，我們來(lái)詳細(xì)了解一下每層的具體作用：

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

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

MVC 架構(gòu)的弊端

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

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

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

圖片

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

Manager 層的特征

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

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

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

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

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

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

Manager 層使用案例

下面，我們通過(guò)一個(gè)具體的例子來(lái)說(shuō)明 Manager 層的使用場(chǎng)景。

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

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

圖片

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

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

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

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

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

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

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

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

引入 Manager 層后的代碼示例

// DepartmentService.java
public Result<String> upOrDown(Long departmentId, Long swapId) {
    // 驗(yàn)證 1
    DepartmentEntity departmentEntity = departmentDao.selectById(departmentId);
    if (departmentEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗(yàn)證 2
    DepartmentEntity swapEntity = departmentDao.selectById(swapId);
    if (swapEntity == null) {
        return Result.error("部門xxx不存在");
    }
    // 驗(yàn)證 3
    Long count = employeeDao.countByDepartmentId(departmentId);
    if (count != null && count > 0) {
        return Result.error("員工不存在");
    }
    // 操作數(shù)據(jù)庫(kù) 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ù)準(zhǔn)備工作放在 Service 層，然后將數(shù)據(jù)傳遞給 Manager 層。Manager 層添加 @Transactional 事務(wù)注解，負(fù)責(zé)進(jìn)行數(shù)據(jù)庫(kù)操作。這樣一來(lái)，就避免了長(zhǎng)事務(wù)問(wèn)題，提高了系統(tǒng)的性能和可維護(hù)性。

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