面向服務開發中三層架構中事務單元的生命期管理

2021-09-08 03:49:59 字數 1155 閱讀 2725

經典的三層分層結構,控制層(control),服務層(service),持久層(repository)應用廣泛,在面向服務(soa)的架構中,配合di、ioc實現開放靈活的技術架構。

soa中,respository面向資料訪問,提供訪問資料庫、檔案、或其他業務介面提供持久能力。service面向業務,提供訪問業務功能的介面,使用領域模型描述業務需求,方便產品人員、需求人員和客戶溝通理解業務流程。最後,control面向業務流程整合,提供基於事務的需求實現。

事務,用需求來講,就是事情要麼成功,要麼就是沒有變化,不能有中間的不正常狀態。在資料庫事務中,資料庫產品已經提供了資料庫事務,來保證資料修改刪除的事務性,電商支付體系中,也提供了預扣費,消費來保證事務性。

既然事務這麼重要,我們應該在**控制事務呢?控制層、服務層還是持久層?

按照分而治之的思路,應該是持久層服務持久層的事務,服務層控**務的事務,控制層控制這個事務,層層管理,內層事務自治的同時,服從外層事務。互相配合,協同工作完成。

理想中的無事務控制流程和生命期是這樣的,如下圖:

理想中的有事務的流程是這樣,簡圖如下:

但是因為unity/spring的系統中,ioc控制著物件的生命週期,圖中lifescope物件對程式設計師不可見,便會引發集中常見的問題。

1. 完全無視生命期,不進行**

這種情況下,程式的反應是respository每次建立資料庫連線,直到資料庫連線數過多,造成系統宕機。(幾乎沒人使用的系統除外)

2. 每次建立生命期,等框架自動**

此時分兩類,一種對框架比較了解,能正確配置使用並觀察到生命期內物件的**,此時沒有問題。第二種就悲催了,認為框架就應該做好了**,完全自動化**,此時完全看抄的度娘上人什麼水準了,差的情況,一樣會資料庫連線數過多,造成系統宕機。

3. 單例服務改為每次建立,降低效能

有時,為了解決單例服務產生的資料庫連線問題,連線上已經啟動事務等問題,有人把應該為單例的服務配置為每次建立,想依靠服務每次建立,自動建立不懂的資料庫連線。姑且不說服務是不是應該單例存在,這樣每次建立,就會造成極大的效能開銷。

三層架構專案開發

常見的三層架構包括如下幾個部分 資料訪問層 dal 用於實現與資料庫的互動和訪問,從資料庫獲取資料或儲存資料到資料庫的部分。業務邏輯層 bll 業務邏輯層承上啟下,用於對上下互動的資料進行邏輯處理,實現業務目標。表示層 web 主要實現和使用者的互動,接受使用者請求或返回使用者請求的資料結果的展現,...

分層開發(三層架構)

為了實現 高內聚 低耦合 採用 分而治之 的思想,把問題劃分開來各個解決,易於控制,易於延展,易於分配資源。分層的好處 1.實現了軟體之間的解耦,降低元件之間的耦合度 耦合 元件或者 之間的關聯程度 2.便於進行分工,提高開發效率,保證開發質量 3.便於維護 4.提高軟體元件的重用 6.便於產品功能...

三層架構 物件導向思想

物件導向,將資料抽象為乙個個的模型物件,只在程式執行時載入資料,即給模型賦值。以後的操作都是建立在模型的基礎上,直接去操作物件 1 首先,建立模型類model public string code public string name 2 對模型類進行資料初始化,建立類datafillobject ...