關於三層架構的一些想法

dvlue發表於2009-07-21
架構
目前開發人員對系統開發的一個共識是使用三層架構，分為表示層，業務層，和持久層。而這三層之間的依賴關係如何？比較常見的一種看法是

表示層 --&gt 業務層 --&gt 持久層

這表明了層與層之間的呼叫關係，表示層通過呼叫業務層來完成任務，而業務層則呼叫持久層。從另一個角度來看，一種依賴關係是

表示層 --&gt 領域模型(Domain Model)

即表示層和持久層都應該理解(recognize)領域模型。而領域模型則是業務層的一部分。業務層正是系統的價值所在。雖說表示和持久也很重要，在某些系統中可以說是很關鍵，但是它們的最終目的都是為業務服務，所以業務層應該是系統的核心。

基於以上的認識，在系統設計的時應首先分析需求得到領域模型，找出系統中的實體、物件（靜態的一面），並明確大致的業務流程(動態的一面)。 而另兩層應盡最大努力為業務層服務，且儘量減少業務層受另兩層的限制。


各層的職責：

表示層：負責顯示資訊，及從系統外部得到輸入。表示層的設計決定系統介面的可用性，及資訊輸入和展示的可靠性。表示層只知道如何展示資訊，及收集使用者輸入，並不知道該如何對這些輸入進行處理來完成業務。

業務層：完成業務邏輯。業務層設計決定客戶價值是否能夠得到實現。這是系統的關鍵。外在的表現是功能性。業務層設計和實現的失誤表現在使用者端即功能缺失，功能不可靠等。如果需要對業務層的業務規則進行解耦，則可以使用規則引擎如Drools，把業務規則分離出來。但分離後的業務規則仍屬於業務層。業務層知道如何對使用者輸入進行處理，能夠應用業務規則完成使用者所需的業務，但它不知道資料如何讀取和儲存。

持久層：負責使用者資訊的持久化。持久層的失誤表現在外即資料處理(儲存，展示等)不可靠。持久層完全不知道業務，只專注於資料儲存和讀取。所謂持久化並不一定是指資料庫，任何方式的持久化(通過檔案，網路的持久化等)都應由持久層完成。

各層的設計都會直接影響系統效能。

三層的體積大小和複雜度在不同的系統中可能會有很大的不同。比如說GOOGLE的搜尋引擎，它的介面很簡單，可以想像表示層是比較容易實現的，而它的業務層，關係到處理關鍵字，分析搜尋結果，決定排名等，而持久層則要負責處理超大量的資料。業務層和持久層則相當複雜。而有的系統持久層會很小，比如防毒軟體，媒體播放軟體等。業務層小而另兩層大的例子暫時還沒有想到:)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7656893/viewspace-609786/，如需轉載，請註明出處，否則將追究法律責任。

相關文章