《企業應用架構模式》（POEAA）讀書筆記

原文地址： 《企業應用架構模式》（POEAA）讀書筆記 做者： 鄒齊龍(技術-5013

什麼是架構

• Rolph Johnson認爲：架構是一種主觀上的東西，是專家級的項目開發人員對系統設計的一些可共享的理解
• 架構中包括一些決定，開發者但願這些決定能儘早做出，由於在開發者看來它們是難以改變的。
•  若是你發現某些決定不像你想象中的那麼難以改變，那麼它就再也不與架構相關
• 理解： B/S (SmartClient、C/S) 架構， DotNet 架構， J2EE架構

企業應用的特色

1. 涉及到持久化數據
2. 不少人同時訪問數據
3. 含有大量操做數據的用戶界面
4. 與散佈在企業內部或周圍的其餘的應用集成
5. 各類異構系統的概念含有不一致性
6. 業務邏輯一般是最沒有邏輯的東西
7. 企業應用並不是都是大型的，但可能都爲企業提供巨大的價值

  · 性能：不少時候，增長更多的服務器比增長更多的程序員便宜；若是增長服務器對性能的提高較大，則說明應用的伸縮性好 

· 分層：上層是用下層定義的各類服務，而下層對上層一無所知；分層的缺陷是不能封裝全部的東西，所以可能帶來級聯更改，過多的層影響性能；Layer和Tier的區別是Tier可能更多的意味物理上的分離      

Brown分層模型

表現層>>控制層>>領域層>>數據映射層>>數據源層  

Core J2EE分層模型

客戶層>>表現層>>業務層>>集成層>>資源層 

MS DNA分層模型

表現層>>業務邏輯層>>數據訪問層 

Marinescu分層模型

表現層>>應用層>>服務層>>領域層>>持久層


· 領域模型：使用不一樣職責的對象來聯合解決業務問題，而不是經過事務腳原本處理數據 

· 阻抗不匹配：對象模型和關係型數據庫之間的不匹配，一般經過對象-關係映射(ORM)解決 

· 軟件事務的四個特性 

1.      原子性：要麼所有成功，要麼所有回滾

2.      一致性：事務開始和完成時，資源都不該該被破壞

3.      隔離性：事務成功完成以前，其影響不該該被看到

4.      持久性：事務不會由於任何崩潰而丟失更改 

· 事務的隔離級別（由高而低）

1.      可串行化：徹底隔離，併發執行的結果與以某種順序依次執行的結果相同

2.      可重複讀：容許幻讀，更新者向集合中插入了一些元素而讀的人只能看到其中一部分

3.      讀已提交：容許不可重複讀，全部已經提交的數據均可以讀

4.      讀未提交：容許髒讀，容許讀未提交的數據 

· 會話狀態：無狀態對象是一種不良設計；用無狀態的服務器能夠實現有狀態的會話；若是有不少會話空閒，能夠考慮用數據庫存儲會話；若是須要頻繁訪問會話，則應該使用服務器會話 

· 分佈策略：分佈對象的第必定律：不要使用分佈對象；分佈對象的第二定律：節約使用分佈對象

領域邏輯模式分爲 事物腳本、領域模型、表模塊和服務層四種模式

　　不少設計者喜歡把業務邏輯分紅兩類：領域邏輯和應用邏輯，前者只與問題領域有關、然後者有時被稱爲工做流邏輯

1. 事務腳本

　　經過使用SQL語句或者存儲過程返回記錄集，記錄集在系統的各層之間傳遞，在必要的時候能夠經過更新記錄集、使用SQL語句或者存儲過程的方式更新數據庫
　　事務腳本勝在簡單，一般應用在小型的項目和系統中，但業務邏輯愈來愈複雜，使用這一模式就愈來愈難以保持良好設計，由於在程序裏面充斥了大量的SQL語句和命令，一旦數據結構發生更改或者須要對系統進行修改，可能會出現許多難以發現的問題

2. 領域模型

　　領域模型是合併了行爲和數據的領域的對象模型，領域模型建立了一張由互聯對象組成的網，其中的每一個對象都表明着某個有意義的個體，可能大到一個公司或者小到訂單的一行

　　簡單領域可使用活動記錄，即簡單的單條數據記錄和單個對象對應的模式，一個對象對應數據庫中的一個表

　　複雜領域模型須要使用數據映射器，它可能使用繼承、策略或者其餘的設計模式，是一張由互聯的細粒度對象組成的複雜網絡，咱們常常會看到：多個類經過交互來完成很簡單的任務

　　在面向對象技術中，經過從一個對象到另外一個對象的連續傳遞能夠把行爲傳遞給最有資格處理的對象，它同時消除了不少條件判斷行爲

領域模型的要點在於隱藏數據庫的存在

3. 表模塊

　　表模塊是處理某一數據庫表或視圖中全部行的業務邏輯的一個實例

　　表模塊經過強類型或弱類型的數據集與對象結合使用，使用主鍵查詢數據，是.Net中使用的不少的一種模式，主要使用主鍵、半對象化的操做數據---之因此說是半結構化，是由於所用的對象基本上只具備行爲，經過傳入參數執行特定的操做或者查詢記錄集，而幾乎不承載任何數據

　　在.net中，這種模式由於其容易和UI進行綁定和交互，因此倍受歡迎

4. 服務層

　　經過一個服務層來定義應用程序邊界，在服務層中創建一組可用的操做的集合，並在每一個操做內部協調應用程序的響應

　　服務層是一種組織業務邏輯的模式，有點相似於業務外觀；WEB SERVICE一般擔任着服務層的角色

　　服務層能夠經過領域外觀方法和操做腳本方法實現，領域外觀方法中，服務層以領域模型之上的瘦外觀集合方式出現，負責實現外觀的類中不不包含業務邏輯；而在操做腳本方法中 ，服務層由一組相對複雜的類組成，這些類直接實現應用邏輯，但將領域邏輯委託給封裝好的領域對象類

 　　服務層的類的接口是粗粒度的，適合於遠程調用。可是，在開始時，咱們應該僅設計一個本地調用的服務層，在須要遠程調用時，再在服務層上增長一個遠程外觀。

併發管理的正確目標是儘可能增長對數據的正確訪問，同時減小衝突
　　離線併發模式有兩種：使用樂觀離線鎖、使用悲觀離線鎖

　　離線鎖能夠理解爲一種非服務器管理的鎖，或者說是自管理的鎖，應用在適當的地方註冊鎖，獲取數據，而後離線，並對數據進行離線的操做；其餘的應用經過檢測已經註冊的鎖來決定是否進行併發操做

1. 悲觀離線鎖

 　　悲觀離線鎖假設會話衝突的可能性很大，從而對系統的併發進性進行限制
 　　在對不一致讀的要求不高時，第一選擇是使用獨佔寫鎖（不能夠再添加任何讀鎖，固然寫鎖也不能）；如必須讀出最新數據，而不在意是否要修改，則應使用獨佔讀鎖（不能夠再添加任何寫鎖，但讀鎖是容許的）。結合以上兩種，提供互斥讀鎖的限制，又有互斥寫鎖的併發性的鎖稱爲 讀/寫鎖---讀/寫鎖互斥不能同時加，但併發的讀鎖是容許的
 　　構建悲觀離線鎖的步驟：決定使用哪一種鎖>>構建一個鎖管理對象>>定義業務事務使用鎖的過程
 　　讓鎖管理對象在鎖不可用時拋出異常而不是等待鎖釋放，能夠免除死鎖
 　　悲觀離線鎖做爲樂觀離線鎖的補充，只在真正須要的時候才應該使用 

2. 樂觀離線鎖

 　　樂觀離線鎖假設會話衝突的可能性很小，從而使得多用戶對一份數據進行處理成爲可能　　經過沖突檢測和事務會滾來防止併發事務中的衝突　　本質就是經過將會話中的版本號與當前記錄數據的版本號相比較，事務成功提交之後版本號增長；或者在更新的SQL語句中包含對全部字段的檢查，能夠不須要爲數據庫增長版本字段，但可能致使性能損失　　樂觀離線鎖必須自定檢查以防止不一致讀　　一個高效的合併策略能使樂觀離線鎖變得很是強大，當衝突發生時，合併策略能夠合併更改並從新提交