文章目錄

• 規范
• 對比傳統MVC
• 小栗子
• • V1.0 傳統寫法
  • V2.0 引入Manager層
• 源碼

---

規范

---

對比傳統MVC

說幾個弊端

• Service層代碼臃腫

• Service層易出現大事務，事務嵌套，易出問題且難排查

• dao層混雜業務邏輯

• dao層sql語句復雜

• …

為了解決這個問題，《阿里巴巴泰山版java開發手冊》推薦在Service層之下獨立出一個通用業務處理層（Manager層）

相比較傳統的MVC，主要增加了 Manager 層， 它有如下特征：

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

---

實際開發中，

• 對于復雜業務，service調用manager層，然后把事務下沉到Manager層，Manager層不允許相互調用，不會出現事務嵌套。

• 專注于不帶業務SQL，也可以在manager層進行通用業務的dao層封裝。

• 避免復雜的join查詢，可以在manager層嚴格控制好SQL，應對復雜的SQL查詢。

簡言之， Manager 層提供原子服務接口，Service 層負責依據業務邏輯來調用原子接口。

---

小栗子

舉個例子說明一下Manager層的使用場景

需求：

APP 登錄的用戶，如果系統中沒有用戶，需要自動創建用戶，然后再返回相關的用戶信息用于展示

網頁端登陸的用戶，如果系統中沒有用戶，不自動創建用戶，需要用戶注冊。

反手就是一頓突突啊

---

V1.0 傳統寫法

package com.artisan.service;import com.artisan.dao.UserDao; import com.artisan.response.ResponseData; import lombok.SneakyThrows; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional;import java.util.concurrent.TimeUnit;/*** @author 小工匠* @version 1.0* @mark: show me the code , change the world*/@Service public class ServiceWithoutManager {private final boolean APP = true;@Autowiredprivate UserDao userDao;@Transactional(rollbackFor = Throwable.class)public ResponseData<String> buiz(Long idCard, Long name) {// 驗證 1 假設 DB操作 校驗String var1 = doDBCheck1();// 驗證 2 假設 DB操作 校驗String var2 = doDBCheck2();// 業務 APP -- DB校驗 --- 自動創建用戶 -- 返回用戶信息// 網頁 -- DB校驗 --- -- 返回用戶信息doBiz(var1,var2);return ResponseData.success("success");}@SneakyThrowsprivate void doBiz(String a ,String b) {if(APP) {// 模擬業務耗時TimeUnit.MILLISECONDS.sleep(1200);}else {}}@SneakyThrowsprivate String doDBCheck2() {// 模擬業務耗時TimeUnit.MILLISECONDS.sleep(500);return "";}@SneakyThrowsprivate String doDBCheck1() {// 模擬業務耗時TimeUnit.MILLISECONDS.sleep(1000);return "";}}

這有啥子問題？ 常規操作啊…

每日一博 - 常見的Spring事務失效&事務不回滾案例集錦

讓我們來分析分析

• 典型的長事務問題 ， 由于方法上有@Transactional 注解，所以驗證和業務都是使用的同一個 connection
• 對于復雜業務、復雜的驗證邏輯，會導致整個驗證過程始終占用該 connection 連接，占用時間可能會很長，直至方法結束，connection 才會交還給數據庫連接池。

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

@Transactional 注解， AOP 實現，本質就是在目標方法執行前后進行攔截。 在目標方法執行前加入或創建一個事務，在執行方法執行后，根據實際情況選擇提交或是回滾事務。

當 Spring 遇到該注解時，會自動從數據庫連接池中獲取 connection，并開啟事務然后綁定到 ThreadLocal 上，對于@Transactional注解包裹的整個方法都是使用同一個connection連接。

如果出現了耗時的操作，比如三方接口調用，業務邏輯復雜，大數據處理等就會導致占用這個connection的時間過長，數據庫連接一直被占用不釋放。一旦類似操作過多，進而導致數據庫連接池耗盡。

---

V2.0 引入Manager層

將數據在 service 層準備好，然后傳遞給 manager 層，由 manager 層添加@Transactional事務注解進行數據庫操作, 盡量減少大事務帶來的危害。

源碼

https://github.com/yangshangwei/boot2

總結

以上是生活随笔為你收集整理的SpringBoot - 实践阿里巴巴【Manager 层_通用业务处理层】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。