網(wǎng)易二面：阿里為何建議MVC+Manager層混合架構(gòu)？
初入編程世界時，前輩們總會教導(dǎo)我們，系統(tǒng)設(shè)計應(yīng)遵循 MVC（Model - View - Controller） 架構(gòu)。MVC 架構(gòu)就像一個精巧的齒輪組，將整個系統(tǒng)清晰地劃分為 Model（模型）、View（視圖）和 Controller（控制器）三個層次。它巧妙地把用戶視圖和業(yè)務(wù)處理隔離開來，再通過控制器將它們緊密連接，如同搭建起一座溝通的橋梁，實現(xiàn)了表現(xiàn)與邏輯的完美解耦，是軟件分層架構(gòu)中的經(jīng)典范式。
三層架構(gòu)
MVC 分層架構(gòu)是架構(gòu)領(lǐng)域中最為基礎(chǔ)和簡單的分層方式。當(dāng)我們依據(jù)這種架構(gòu)構(gòu)建項目時，通常會創(chuàng)建三個關(guān)鍵目錄：controller、service 和 dao，它們分別對應(yīng)著表現(xiàn)層、邏輯層和數(shù)據(jù)訪問層。
圖片
下面，我們來詳細(xì)了解一下每層的具體作用：
- Controller 層：它就像是交通樞紐的指揮者，主要負(fù)責(zé)對訪問請求進(jìn)行轉(zhuǎn)發(fā)。同時，它還承擔(dān)著各類基本參數(shù)的校驗工作，對于一些無需復(fù)用的簡單業(yè)務(wù)，也可以在這里直接處理。
- Service 層：這是業(yè)務(wù)邏輯處理的核心地帶，如同一位技藝精湛的工匠，精心雕琢著每一個業(yè)務(wù)流程。同時，它還負(fù)責(zé)管理事務(wù)，確保數(shù)據(jù)的一致性和完整性。
- Dao 層：它是與底層數(shù)據(jù)庫（如 MySQL、Oracle 等）進(jìn)行數(shù)據(jù)交互的橋梁，負(fù)責(zé)將業(yè)務(wù)邏輯層的請求轉(zhuǎn)化為數(shù)據(jù)庫操作，為系統(tǒng)提供穩(wěn)定的數(shù)據(jù)支持。
然而，隨著業(yè)務(wù)的不斷發(fā)展和代碼量的持續(xù)增加，這種看似簡單明了的三層架構(gòu)逐漸暴露出一些問題。
MVC 架構(gòu)的弊端
傳統(tǒng)的 MVC 分層架構(gòu)存在以下幾個較為明顯的問題：
- Service 層代碼臃腫：隨著業(yè)務(wù)邏輯的日益復(fù)雜，Service 層需要處理的任務(wù)越來越多，代碼量不斷膨脹，在此，我想給大家送個福利，關(guān)注工眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 即可獲取阿里內(nèi)部 Java 性能優(yōu)化手冊。導(dǎo)致代碼的可讀性和可維護(hù)性急劇下降。
- Service 層事務(wù)問題頻發(fā)：在 Service 層，大事務(wù)和事務(wù)嵌套的情況時有發(fā)生。這些問題不僅會導(dǎo)致系統(tǒng)性能下降，還會使問題的排查變得異常困難，給開發(fā)和維護(hù)工作帶來巨大挑戰(zhàn)。
- Dao 層業(yè)務(wù)邏輯混雜：Dao 層原本應(yīng)該專注于數(shù)據(jù)訪問，但在實際開發(fā)中，往往會摻雜一些業(yè)務(wù)邏輯，這使得代碼的職責(zé)不夠清晰，增加了代碼的耦合度。
- Dao 層 SQL 語句復(fù)雜：隨著業(yè)務(wù)的發(fā)展，Dao 層的 SQL 語句變得越來越復(fù)雜，關(guān)聯(lián)查詢大量增加。這不僅會影響數(shù)據(jù)庫的性能，還會增加代碼的維護(hù)難度。
為了解決這些問題，我們可以參考《alibaba java 開發(fā)手冊》，在 Service 層之下新增一個通用業(yè)務(wù)處理層——Manager 層。
圖片
在這個新的分層架構(gòu)中，Manager 層與 Service 層相互協(xié)作，各司其職。Manager 層提供原子性的服務(wù)接口，就像一個個標(biāo)準(zhǔn)化的零件；而 Service 層則根據(jù)業(yè)務(wù)邏輯的需求，對這些原子接口進(jìn)行編排組合，構(gòu)建出完整的業(yè)務(wù)流程。
Manager 層的特征
《alibaba java 開發(fā)手冊》對 Manager 層有如下描述：
Manager 層作為通用業(yè)務(wù)處理層，具有以下顯著特征：
- 第三方平臺封裝層：負(fù)責(zé)對第三方平臺的接口進(jìn)行封裝，對返回結(jié)果進(jìn)行預(yù)處理，并將異常信息進(jìn)行轉(zhuǎn)化，以適配上層接口的需求。
- Service 層通用能力下沉：將 Service 層的一些通用能力下沉到 Manager 層，如緩存方案的實現(xiàn)、中間件的通用處理等，提高代碼的復(fù)用性和可維護(hù)性。
- DAO 層組合復(fù)用：與 DAO 層進(jìn)行交互，對多個 DAO 進(jìn)行組合復(fù)用，實現(xiàn)復(fù)雜業(yè)務(wù)的數(shù)據(jù)訪問需求。
在實際開發(fā)中，我們可以按照以下方式使用 Manager 層：
- 復(fù)雜業(yè)務(wù)處理：對于復(fù)雜的業(yè)務(wù)場景，Service 層負(fù)責(zé)準(zhǔn)備好所需的數(shù)據(jù)，并將其傳遞給 Manager 層。Manager 層負(fù)責(zé)業(yè)務(wù)的編排和事務(wù)的處理，并且不允許相互調(diào)用，避免出現(xiàn)事務(wù)嵌套的問題。
- 通用業(yè)務(wù) DAO 封裝：Manager 層專注于編寫不包含業(yè)務(wù)邏輯的 SQL 語言，對通用業(yè)務(wù)進(jìn)行 DAO 層的封裝，提高代碼的復(fù)用性和可維護(hù)性。
- 復(fù)雜查詢拆分：為了避免復(fù)雜的 join 查詢對數(shù)據(jù)庫造成過大壓力，我們可以在 Manager 層對復(fù)雜查詢進(jìn)行拆分，將其轉(zhuǎn)化為多個簡單的查詢，減輕數(shù)據(jù)庫的負(fù)擔(dān)。
需要注意的是，對于簡單的業(yè)務(wù)場景，我們可以不使用 Manager 層，以免增加系統(tǒng)的復(fù)雜度。
Manager 層使用案例
下面，我們通過一個具體的例子來說明 Manager 層的使用場景。
假設(shè)我們有一個用戶系統(tǒng)，其中有一個獲取用戶信息的接口。在傳統(tǒng)的三層架構(gòu)中，該接口調(diào)用邏輯 Service 層的 getUser 方法，getUser 方法再與 User DB 交互獲取數(shù)據(jù)，具體流程如左圖所示。
這時，產(chǎn)品提出了一個新的需求：在 APP 中展示用戶信息時，如果用戶不存在，需要自動為用戶創(chuàng)建一個新用戶。同時，HTML5 頁面需要保留之前的邏輯，即不需要創(chuàng)建用戶。
圖片
在傳統(tǒng)的三層架構(gòu)下，邏輯層的邊界變得模糊不清，表現(xiàn)層也不得不承擔(dān)一部分業(yè)務(wù)邏輯。我們通常會在表現(xiàn)層 Controller 中添加業(yè)務(wù)邏輯處理代碼，將獲取用戶和創(chuàng)建用戶的接口進(jìn)行編排。
而引入 Manager 層之后，情況就大不一樣了。Manager 層提供創(chuàng)建用戶和獲取用戶信息的接口，就像提供了兩個獨立的工具；Service 層則負(fù)責(zé)將這兩個接口進(jìn)行組裝，構(gòu)建出完整的業(yè)務(wù)流程。這樣一來，原本分散在表現(xiàn)層的業(yè)務(wù)邏輯就被統(tǒng)一到了 Service 層，每一層的職責(zé)更加清晰明確。
接下來，我們通過一段實際代碼來看看 Service 層與 Manager 層是如何區(qū)分的。
傳統(tǒng)三層架構(gòu)代碼示例
@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)的三層架構(gòu)中很常見，但它存在一個明顯的問題——長事務(wù)問題（類似的情況還包括調(diào)用第三方接口）。在這段代碼中，前三步的驗證操作都使用了同一個數(shù)據(jù)庫連接 connection。由于方法上添加了 @Transactional 注解，整個驗證過程會一直占用該連接，占用時間可能會很長，直到方法執(zhí)行結(jié)束，連接才會被歸還給數(shù)據(jù)庫連接池。
對于復(fù)雜業(yè)務(wù)來說，這種長時間占用同一個數(shù)據(jù)庫連接的做法并不是一個好的選擇。我們應(yīng)該盡量縮短連接的占用時間，提高系統(tǒng)的性能和并發(fā)處理能力。
說明：對于@Transactional 注解，當(dāng) spring 遇到該注解時，會自動從數(shù)據(jù)庫連接池中獲取 connection，并開啟事務(wù)然后綁定到 ThreadLocal 上，如果業(yè)務(wù)并沒有進(jìn)入到最終的 操作數(shù)據(jù)庫環(huán)節(jié)，那么就沒有必要獲取連接并開啟事務(wù)，應(yīng)該直接將 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ù)準(zhǔn)備工作放在 Service 層，然后將數(shù)據(jù)傳遞給 Manager 層。Manager 層添加 @Transactional 事務(wù)注解，負(fù)責(zé)進(jìn)行數(shù)據(jù)庫操作。這樣一來，就避免了長事務(wù)問題，提高了系統(tǒng)的性能和可維護(hù)性。
通過以上的分析和示例，我們可以看到，引入 Manager 層可以有效地解決傳統(tǒng) MVC 三層架構(gòu)中存在的問題，使系統(tǒng)的架構(gòu)更加清晰、合理，提高系統(tǒng)的可維護(hù)性和性能。希望本文對大家在系統(tǒng)架構(gòu)設(shè)計方面有所幫助。
