java開發MVC三層架構上再加一層Manager層原理詳解

Posted on by

MVC三層架構

我們在剛剛成為程序員的時候，就會被前輩們 “教育” 說系統的設計要遵循 MVC（Model-View-Controller）架構。它將整體的系統分成瞭 Model（模型），View（視圖）和 Controller（控制器）三個層次，也就是將用戶視圖和業務處理隔離開，並且通過控制器連接起來，很好地實現瞭表現和邏輯的解耦，是一種標準的軟件分層架構。

MVC分層架構

MVC分層架構是架構上最簡單的一種分層方式。為瞭遵循這種分層架構我們在構建項目時往往會建立這樣三個目錄：controller、service 和 dao，它們分別對應瞭表現層、邏輯層還有數據訪問層。

三層架構示意圖

每層的作用如下：

Controller層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理。

Service層：主要是處理業務邏輯和事務

Dao層：負責與底層數據庫MySQL，Oracle等進行數據交互

可是隨著我們的業務邏輯越來復雜，代碼寫的越來越多，這種簡單的三層架構的問題也越來越明顯。

MVC架構弊端

傳統的MVC分層有以下幾個很明顯的問題：

Service層代碼臃腫

Service層很容易出現大事務，事務嵌套，導致問題很多，而且極難排查

dao層參雜業務邏輯

dao層sql語句復雜，關聯查詢比較多

為瞭解決這個問題，我們參考《alibaba java開發手冊》，在Service層之下再獨立出一個通用業務處理層（Manager層）

manager層

在這個分層架構中主要增加瞭 Manager 層，它與 Service 層的關系是：Manager 層提供原子的服務接口，Service 層負責依據業務邏輯來編排原子接口。

Manager層的特征

在《alibaba java開發手冊》中是這樣描述Manager層的：

Manager 層：通用業務處理層，它有如下特征：

對第三方平臺封裝的層，預處理返回結果及轉化異常信息，適配上層接口；對 Service 層通用能力的下沉，如緩存方案、中間件通用處理；與 DAO 層交互，對多個 DAO 的組合復用。

在實際開發中我們可以這樣使用Manager層

復雜業務，service提供數據給Manager層，負責業務編排，然後把事務下沉到Manager層，Manager層不允許相互調用，不會出現事務嵌套。

專註於不帶業務sql語言，也可以在manager層進行通用業務的dao層封裝。

避免復雜的join查詢，數據庫壓力比java大很多，所以要嚴格控制好sql，所以可以在manager層進行拆分，比如復雜查詢。

當然對於簡單的業務，可以不使用Manager層。

Manager層使用案例

這裡我們舉個例子說明一下Manager層的使用場景：

假設你有一個用戶系統，他有一個獲取用戶信息的接口，它調用邏輯Service層的 getUser 方法，getUser方法又和 User DB 交互獲取數據。如下圖左邊展示部分。

這時，產品提出一個需求，在 APP 中展示用戶信息的時候，如果用戶不存在，那麼要自動給用戶創建一個用戶。同時，要做一個 HTML5 的頁面，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 註解，所以這三個驗證都是使用的同一個 connection。

若對於復雜業務、復雜的驗證邏輯，會導致整個驗證過程始終占用該 connection 連接，占用時間可能會很長，直至方法結束，connection 才會交還給數據庫連接池。

對於復雜業務的不可預計的情況，長時間占用同一個 connection 連接不是好的事情，應該盡量縮短占用時間。

說明：對於@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(departmentSort,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);
}

將數據在 service 層準備好，然後傳遞給 manager 層，由 manager 層添加 @Transactional事務註解進行數據庫操作。

以上就是MVC三層架構上再加一層Manager層原理詳解的詳細內容，更多關於MVC架構Manager層原理的資料請關註WalkonNet其它相關文章！

推薦閱讀：