1　　　　　 企業應用模式概述

　　1.1　　　 企業應用的模式

　　企業應用領域要解決的問題在某些方面要比做一個工具軟件、或者一個電信通信軟件等復雜的得多，比如紛雜的企業數據，各具特色的業務規則，變化莫測的用戶需求。因此企業應用開發技術從CORBA、COM、J2EE、_NET等等，層出不窮，每一種技術的出現，都為企業問題的解決題供了一種思路，一個選擇。

　　既然企業的問題是特定，那么我們就可以把問題進行分類，并把每一類問題的解決方法記錄下來，這樣，就形成了一套我們解決問題的思路，這就是模式。模式的核心就是特定的解決方案，它有效且有足夠的通用性。借用一下Christopher Alexander給出的模式的定義：“每一個模式描述了一個在我們周圍不斷重復發生的問題以及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復勞動”。

　　模式的關鍵點是它們來源于實踐，他必須觀察人們的工作過程，發現其中好的設計，并找出這些解決方案的核心，一旦發現了某個模式，那將是非常有價值的。當然，如果要學習一個模式，只是需要了解這些模式是干什么的、解決了那些問題、是如何解決問題的，就足夠了。

　　 企業架構的領域問題有許多，如分層架構、Web表現、業務邏輯、數據庫映射、并發、會話、分布策略、異步通信、安全、錯誤處理、集群、應用集成、架構重構。在此只選擇了其中企業級應用程序的分層、構建基于Web的用戶界面、構建領域業務邏輯、將內存模塊關聯到關系數據庫、事務與并發、無狀態環境下的會話狀態、分布策略等七個方面的問題進行了總結討論。

　　1.2　　　 企業應用的特點與術語

企業應用是什么是一個比較難以回答問題，但通常企業應用一般會涉及到持久化數據、會涉及到大量的數據、會涉及多人同時訪問數據、會涉及到大量操作數據的用戶界面屏幕，還會有一些特定的業務邏輯，盡管在企業應用中，業務邏輯通常是最沒有邏輯的

企業應用中性能的要求：

　　響應時間是系統完成一次外部請求所需的時間。

　　響應性是系統響應請求的速度有多快。

　　等待時間是獲得系統任何形式響應的最小時間，如果在本機一般都會得到響應，如果在遠程計算機上，響應時間就跟傳輸時間相關了。

　　吞吐率是給定時間內能夠處理多大的請求量，對企業應用，吞吐率通常是每秒的事務數(tps)來度量。

　　在此處，對用戶體驗最明顯的是響應性，有時候，為了響應性，損失一些響應時間或者吞吐率是值得的。

　　負載是關于系統當前負荷的表述，負荷可以是多種多樣的，比如可以用連接的用戶數來表示負荷，通常作為其他指標的背景：如20個用戶響應時間5秒。

　　負載敏感度是指響應時間隨負載變化的程度。

　　效率是性能除以資源。

　　系統的容量是指最大有效負載或吞吐率的指標。

　　可伸縮性是指系統中增加資源（通常是硬件）對系統性能的影響。一個可伸縮的系統允許在添加了硬件后，能夠有性能上的合理提高。垂直可伸縮通常指增加服務器性能，水平可伸縮通常指增加服務器數目。

　　2　　　　　 企業應用的分層

　　在分解復雜的軟件系統時，分層是使用得最多的技術之一。計算機領域中到處都有分層的影子。

　　合理的分層可以1屏蔽底層的細節，2替換某層的實現，實現良好的低耦合。但是分層也有不足之處，1過多的層次會影響性能，2嚴格的分層在企業應用中會造成修改的級聯，比如界面增加一個字段，會影響下面的所有層次。

　　當人們討論分層的時候，常常不易區分layer和tier的區別，在人們的理解中，tier通常意味著物理上的分離，比如客戶/服務器通常被稱為”two-tier system” 。

　　企業應用的三個基本分層討論：表現層、領域層、數據源層。

表現層：表現層處理用戶與軟件間的交互。表現層的主要職責是向用戶現實信息并把從用戶那里獲取的信息解釋成領域層或者數據源層上的各種動作。

　　數據源邏輯主要關注與其他系統的交互，如事務監控、消息系統，最主要的數據源邏輯是數據庫，其職責是持久化數據。

　　領域邏輯也稱業務邏輯，主要職責是根據輸入進行計算、對表現層的輸入進行驗證、以及根據表現層的命令決定調度那些數據源邏輯。

　　在實際的應用中，嚴格的清晰分層是比較難以實現的，在有些應用中，表現層直接訪問數據層，也運轉良好；但是對于復雜的系統，為了日后的維護，我們需要保持這種三層的風格，并且在開發過程中至少也應該堅持某種形式上的分離，至少在子程序（函數）級別。

　　伴隨著分離，有一種普遍原則：那就是領域層和數據層絕對不能依賴表現層，因為表現層是對用戶的接口，是變化的最頻繁的地方，解除依賴可以方便日后替換表現層。確定一個邏輯（方法）是否放到領域層或表現層有一種簡單的方法，那就是，再增加一個表現層，如果這個方法需要重復編寫，那么這個邏輯就應該是領域層的邏輯。比如，如果判斷經理和職員來顯示某個功能的邏輯，對系統來說就應該傳入用戶的id，傳出true或者false。界面層只依賴于true和false。

　　3　　　　　 領域邏輯模式（領域邏輯設計相關）

　　領域邏輯通常有三種方法：事務腳本、表模塊、領域模型。在可以表模塊或者領域模型的系統中，通常會再細分一個服務層，對于事務腳本能夠實現系統，通常沒有必要劃分服務層了。如果在開發環境（visal studio,.Net）擁有大量記錄集工具的環境下，使用表模塊還是很吸引人的。

　　3.1　　　 事務腳本

　　 基于的思想：大多數企業的應用都可以被看作是一系列的事務，一個事務可能將某種信息看作是以特定方式組織的，然后另一事務會改變他，

事務邏輯腳本將所有的事務邏輯組織成單個過程，在過程中直接調用數據庫，或者用一個簡單的數據封裝器。每個事務都由自己的事務腳本，盡管事務間的公共子任務可以被分解為多個子程序。

　　 特點：許多事務腳本的設計中都有直接操作數據庫的操作，有些把SQL語句直接放到數據庫中。

　　 *評論：

　　 此處作者的事務腳本的概念在是，在程序編碼當中，在一個或者幾個方法中進行的直接操作數據庫獲取數據，進行判斷邏輯、并回寫數據庫進行持久化的操作。這些操作為了完成某些業務，沒有特殊的組織，一般沒有經過精心設計的程序都可以歸為事務腳本階段。這是從編碼風格角度來說的。

　　 在此，可以基于事務的思想，可以提出其它優化方法：

　　1〉使用數據庫的存儲過程來實現某些事務過程。書寫方便，執行效率高，而且易于修改（不怕規則變動了）。目前我們的MIS系統中通常使用這種方式，但是，如果規則多了，事務腳本太多，管理不方便，而且，許多小的操作，不是頻繁操作數據庫的事務規則用數據庫腳本就不合適了。

　　2〉基于《GOF設計模式》中 Command模式,將事務腳本組織起來，方便調用和管理。

　　3） 基于《GOF設計模式》中interpreter模式，將自己的腳本抽取為領域規則，使用自己的規則解釋器去解釋這個規則，最終形成自己的“領域標簽”，終極模式是形成類SQL的規則語言。目前有些成熟的產品已經形成了自己的領域規則，并有自己的規則編寫器，這樣程序的二次開發問題能解決好多。軟件產品中使用這個方法可以降低維護成本及解決產品定制問題，但是在項目中就不太方便了。

3.2　　　 領域模型

　　基于的思想：如果領域邏輯規則太復雜了，就需要使用面向對象的方法來解決這個問題。面向對象將自然界的物體都表示為屬性（數據）和操作，因此足以表達負責的邏輯。但是，映射到數據庫比較困難，通常使用活動記錄或者O/RM產品。

　　EJB和POJO(plain of java object 普通java對象),在java中，如果領域邏輯比較復雜涉及到繼承等操作，建議使用POJO，只有表結構與對象比較類似的情況下，使用ejb.

　　基于領域模型或面向對象的參考書有：[Larman],[Flower AP],[Hay],[Martin and Odell]。

　　3.3　　　 表模塊

　　表模塊是用一個類對應數據庫中一個表來組織領域邏輯，而且使用單一的類來包含對數據進行的各種操作。它與領域邏輯的主要區別在于，如果有許多訂單，領域模型使用多個類來處理訂單而表模塊使用單一的類來處理所有訂單。

　　表模塊的長處是允許類和數據綁定在一起，可以充分利用關系數據庫的優點。表模塊看起來和常規的對象很象，但關鍵區別在于它沒有標識出來所代表的常規對象。

　　表模塊可以是一個實例也可以是一個靜態方法的集合。

　　表模塊的入口：表模塊封裝的是一個記錄集，那么形成記錄集的入口通常有兩個，一個是在構造函數或者初始化入口中使用查詢語句，另一種就是在入口中傳遞一個表數據(如recordset)，這樣的優點是封裝了數據的生成，這個表模塊可以面對多個數據源，并且你可以不用數據庫就測試領域邏輯。缺點是多增加了一個用來生成數據的類。

　　比較重要的是，此處的表模塊并不是必須針對每一個數據庫物理表創建一個表模塊，其更多的是針對一個虛擬表結構（如物理視圖或者一個查詢語句）創建模塊。創建表模塊。

如果使用表的結構與對象結構比較類似，則在領域模型中可以使用活動記錄來解決，如果程序中有一個公用的表的結構，實際開發中，人們多傾向于使用表模塊的方式來解決問題，比如微軟平臺中有一個ADO很好的封裝了表，因此在微軟的平臺中，多使用表模塊，而在Java中則沒有這點條件，所以java中使用領域模型的比較多。

在微軟.net平臺中，盡管使用無類型的表模塊更能夠實現平臺無關性，但是有許多實例可以證明使用.net強類型數據集更好。

　　3.4　　　 服務層

　　在領域模型中，通常可以再劃分出來一個服務層，服務層在領域模型之上，封裝了領域模型的實現。服務層定義了系統應用的邊界和從客戶角度看到的各種操作的集合。

　　業務邏輯的分類：服務層是一種組織業務邏輯的模式，通常將業務邏輯分為兩類，應用邏輯和領域邏輯，領域邏輯解決領域問題，應用邏輯與應用的職責相關，通常解決工作流、應用集成的問題。如果應用邏輯與領域邏輯分離，則能是領域邏輯更好的復用。

　　實現方法：服務層可以只是定位到系統操作的集合，這樣只是提供接口對外調用，沒有復雜的邏輯即領域外觀法，領域邏輯也可以提供操作腳本的方法，將數個操作腳本組成一個類，命名為**服務。

　　4　　　　　 數據源架構模式（數據源入口設計相關）

　　4.1　　　 表數據入口

　　作者表述的表數據入口比較簡單，就是使用一個類，封裝了對數據庫表（視圖）的操作，主要有查找，添加，刪除操作，這些操作是根據參數直接使用SQL語句查詢數據庫的。因此多數.net平臺下的程序寫的方法都可以認為是表數據入口。使用ado 中dataset或datatable對象的來保持數據的也算是表數據入庫，只是有了保持數據的操作。

　　4.2　　　 行數據入口

　　最初看到行數據入口，還以為是封裝ado中datarow的操作的，看到示例代碼才明白，就是以類封裝表（視圖）中一行記錄的方式，類本身用屬性或者get,set方法得到字段的值，再加上增、刪、改、查的方法。這種封裝方式，我在重構別人的系統的時候吃過苦頭。系統是VB6的，數據庫某個表字段一修改，就要改類的增、刪、改方法中的傳遞的值，結果類的接口就改變了，VB6把類都作為com對象的，接口改變是要重新生成CLSID的,工程中所有引用此類的方法都要重新編譯（編譯一邊不出錯，再加上打包部署，一個上午就沒有了，僅僅為了一個字段）。最后，我把大部分的類的方法傳遞的參數都修改為 recordset 或者 datarow了。不過，每次想到那個程序，就會提醒我，不是用了類的系統就是面向對象的系統了，拙劣的模仿害死人。

4.3　　　 活動記錄

　　用書中的表述是活動記錄和行數據差不多，就是在行路口封裝的類中有了一些業務邏輯判斷的方法，比如a>b之類的。這個可以作為區分的方法吧。

　　*我認為，活動記錄和行數據就是一個東西，只是在不同的應用場景中的名字，活動記錄是在純粹面向對象解決領域邏輯的術語空間中的名字，行數據的設計方法有有些結構化設計的影子。（術語空間就是說我在家庭這個術語空間內稱為老公，在公司這個術語空間內稱為職員，雖然老公、職員都是我一個人，但是如果換一下，就天下大亂了）

　　4.4　　　 數據影射

　　數據影射是很管用的，可以在對象和數據庫彼此獨立的情況下在兩者之間可以移動的一個影射層。

　　數據影射的方法比較多了，比較笨的方法，我可以用一堆影射類來對應領域層的類，寫sql腳本的方法入庫，我稍微聰明點的話，就是寫一個通用類，加上判斷數據庫中改字段的元數據，自動生成sql語句插入到數據庫中，我很聰明的話，就會寫一個可以通過讀取配置進行數據影射的類了，呵呵，當然非常聰明的話，就去找一個nhibernate,或者其它ORM產品了。不過，用ORM一定很好么？我目前的項目用了一些，只是在單表的情況下用，如果涉及到動輒4-5張表關聯的情況，如果加上代碼表可能有10張表的情況，可能就不太靈光了。

　　5　　　　　 對象關系行為模式（數據源入口設計相關）

　　OR影射，實踐中最難的就是架構及行為方面。行為問題就是如何讓各種對象從數據庫中讀出來又存到數據庫中。

　　5.1　　　 工作單元

　　如果將一個數據庫中數據讀取出來到一個對象中，修改過某些值后，則調用這個對象的更新方法就可以更新到數據庫中，這是沒有問題的。如果程序中在兩個地方都調用了同一條記錄，那么對數據庫更新誰先誰后就有問題了。所以需要使用工作單元的機制，當你讀取的時候，需要注冊一下，保證你只取出來一份，當你更新的時候，工作單元負責你們更新的問題。避免數據覆蓋。如果使用過Ado的話，可以發現微軟的ADO（ado.net）中已經實現了這個問題。

　　5.2　　　 標識映射

　　標識映射，保證你每次取數據庫數據，如果已經生成了此數據的對象，不用每次訪問數據庫。直接將此對象返回。這個挺像《GOF設計模式》中的singleton模式，一個鏡頭變量或者cache可以解決的，標識映射通常放到工作單元中實現。

　　5.3　　　 延遲加載

　　在這個語境下解釋：就是當對象實例化的時候，并不加載從數據庫中加載這個對象，而是加載這個對象的代理，到真正使用這個對象的時候，再加載數據。這樣效率更高一些。《GOF設計模式》中的agent模式是延遲加載的一種解決方法。在動態語言中、和集合類中使使用虛代理比較好，但是在靜態語言中使用虛代理比較困難。

　　值保持器:

　　重影：是允許對象加載部分狀態數據，在訪問某個域的時候，再完全加載這個對象。重影本身也可以看作是虛代理，對象的本身就是自己的虛代理。

轉載于:https://www.cnblogs.com/LHSkey/archive/2010/11/18/1880678.html

總結

以上是生活随笔為你收集整理的企业应用架构模式笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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