關于J2EE層次設計架構實例分析詳解

2019-11-18 12:23:18

字體：大中小

來源：轉載

供稿：網友

　　Part 1 層
　　
　　層（layer）這個概念在計算機領域是非常了不得的一個概念。計算機本身就體現了一種層的概念：系統調用層、設備驅動層、操作系統層、CPU指令集。每個層都負責自己的職責。網絡同樣也是層的概念，最聞名的OSI的七層協議。
　　
　　層到了軟件領域也一樣好用。為什么呢？我們看看使用層技術有什么好處：
　　
　　● 你使用層，但是不需要去了解層的實現細節。
　　● 可以使用另一種技術來改變基礎的層，而不會影響上面的層的應用。
　　● 可以減少不同層之間的依靠。
　　● 輕易制定出層標準。
　　● 底下的層可以用來建立頂上的層的多項服務。當然，層也有弱點：
　　● 層不可能封裝所有的功能，一旦有功能變動，勢必要波及所有的層。
　　● 效率降低。
　　
　　當然，層最難的一個問題還是各個層都有些什么，以及要承擔何種責任。
　　
　　典型的三層結構
　　
　　三層結構估計大家都很熟悉了。就是表示（PResentation）層, 領域（domain）層, 以及基礎架構（infrastrUCture）層。
　　
　　表示層邏輯主要處理用戶和軟件的交互。現在最流行的莫過于視窗圖形界面（wimp）和基于Html的界面了。表示層的主要職責就是為用戶提供信息，以及把用戶的指令翻譯。傳送給業務層和基礎架構層。基礎架構層邏輯包括處理和其他系統的通信，代表系統執行任務。例如數據庫系統交互，和其他應用系統的交互等。大多數的信息系統，這個層的最大的邏輯就是存儲持久數據。
　　
　　還有一個就是領域層邏輯，有時也被叫做業務邏輯。它包括輸入和存儲數據的計算。驗證表示層來的數據，根據表示層的指令指派一個基礎架構層邏輯。
　　
　　領域邏輯中，人們總是搞不清楚什么事領域邏輯，什么是其它邏輯。例如，一個銷售系統中有這樣一個邏輯：假如本月銷售量比上個月增長10％，就要用紅色標記。要實現這個功能，你可能會把邏輯放在表示層中，比較兩個月的數字，假如超出10％，就標記為紅色。
　　
　　這樣做，你就把領域邏輯放到了表示層中了。要分離這兩個層，你應該現在領域層中提供一個方法，用來比較銷售數字的增長。這個方法比較兩個月的數字，并返回boolean類型。表示層則簡單的調用該方法，假如返回true，則標記為紅色。
　　
　　例子
　　
　　層技術不存在說永恒的技巧。如何使用都要看具體的情況才能夠決定，下面我就列出了三個例子：
　　
　　例子1：一個電子商務系統。要求能夠同時處理大量用戶的請求，用戶的范圍遍及全球，而且數字還在不斷增長。但是領域邏輯很簡單，無非是訂單的處理，以及和庫存系統的連接部分。這就要求我們1、表示層要友好，能夠適應最廣泛的用戶，因此采用html技術；2、支持分布式的處理，以勝任同時幾千的訪問； 3、考慮未來的升級。
　　
　　例子2：一個租借系統。系統的用戶少的多，但是領域邏輯很復雜。這就要求我們制作一個領域邏輯非常復雜的系統，另外，還要給他們的用戶提供一個方便的輸入界面。這樣，wimp是一個不錯的選擇。
　　
　　例子3：簡單的系統。非常簡單，用戶少、邏輯少。但是也不是沒有問題，簡單意味著要快速交付，并且還要充分考慮日后的升級。因為需求在不斷的增加之中。
　　
　　何時分層
　　
　　這樣的三個例子，就要求我們不能夠一概而論的解決問題，而是應該針對問題的具體情況制定具體的解決方法。這三個例子比較典型。
　　
　　第二個例子中，可能需要嚴格的分成三個層次，而且可能還要加上另外的中介（mediating）層。例3則不需要，假如你要做的僅是查看數據，那僅需要幾個server頁面來放置所有的邏輯就可以了。
　　
　　我一般會把表示層和領域層/基礎架構層分開。除非領域層/基礎架構層非常的簡單，而我又可以使用工具來輕易的綁定這些層。這種兩層架構的最好的例子就是在VB、PB的環境中，很輕易就可以構建出一個基于SQL數據庫的windows界面的系統。這樣的表示層和基礎架構層非常的一致，但是一旦驗證和計算變得復雜起來，這種方式就存在先天缺陷了。
　　
　　很多時候，領域層和基礎架構層看起來非常類似，這時候，其實是可以把它們放在一起的。可是，當領域層的業務邏輯和基礎架構層的組織方式開始不同的時候，你就需要分開二者。
　　
　　更多的層模式
　　
　　三層的架構是最為通用的，尤其是對IS系統。其它的架構也有，但是并不適用于任何情況。
　　
　　第一種是Brown model [Brown et al]。它有五個層：表示層（Presentation），控制/中介層（Controller/Mediator），領域層（Domain）, 數據映射層（Data Mapping）, 和數據源層（Data Source）。它其實就是在三層架構種增加了兩個中間層。控制/中介層位于表示層和領域層之間，數據映射層位于領域層和基礎架構層之間。
　　
　　表示層和領域層的中介層，我們通常稱之為表示-領域中介層，是一個常用的分層方法，通常針對一些非可視的控件。例如為特定的表示層組織信息格式，在不同的窗口間導航，處理交易邊界，提供Server的facade接口（具體實現原理見設計模式）。最大的危險就是，一些領域邏輯被放到這個層里，影響到其它的表示層。
　　
　　我經常發現把行為分配給表示層是有好處的。這可以簡化問題。但表示層模型會比較復雜，所以，把這些行為放到非可視化的對象中，并提取出一個表示-領域中介層還是值得的。
　　
　　Brown ISA
　　表示層表示層
　　控制/中介層表示-領域中介層
　　領域層領域層
　　數據映射層數據庫交互模式中的Database Mapper
　　數據源層基礎架構層
　　
　　領域層和基礎架構層之間的中介層屬于本書中提到的Database Mapper模式，是三種領域層到數據連接的辦法之一。和表示-領域中介層一眼，有時候有用，但不是所有時候都有用。
　　
　　還有一個好的分層架構是J2EE的架構，這方面的討論可以見『J2EE核心模式』一書。他的分層是客戶層（Client），表示層（Presentation），業務層（Business ），整合層（Integration），資源層（Resource）。差別如下圖：
　　
　　J2EE核心 ISA
　　客戶層運行在客戶機上的表示層
　　表示層運行在服務器上的表示層
　　業務層領域層
　　整合層基礎架構層
　　資源層基礎架構層通信的外部數據
　　
　　微軟的DNA架構定義了三個層：表示層（presentation），業務層（business），和數據存儲層（data access），這和我的架構相似，但是在數據的傳遞方式上還有很大的不同。在微軟的DNA中，各層的操作都基于數據存儲層傳出的SQL查詢結果集。這樣的話，實際上是增加了表示層和業務層同數據存儲層之間的耦合度。 DNA的記錄集在層之間的動作類似于Data Transfer Object。
　　
　　Part 2 組織領域邏輯
　　
　　要組織基于層的系統，首要的是如何組織領域邏輯。領域邏輯的組織有好幾種模式。但其中最重要的莫過于兩種方法：Transation Script和Domain Model。選定了其中的一種，其它的都輕易決定。不過，這兩者之間并沒有一條明顯的分界線。所以如何選取也是門大學問。一般來說，我們認為領域邏輯比較復雜的系統可以采用Domain Model。
　　
　　Transation Script就是對表示層用戶輸入的處理程序。包括驗證和計算，存儲，調用其它系統的操作，把數據回傳給表示層。用戶的一個動作表示一個程序，這個程序可以是script，也可以是transation，也可以是幾個子程序。在例子1中，檢驗，在購物車中增加一本書，顯示遞送狀態，都可以是一個 Transation Script。
　　
　　Domain Model是要建立對應領域名詞的模型，例如例1中的書、購物車等。檢驗、計算等處理都放到領域模型中。
　　
　　Transation Script屬于結構性思維，Domain Model屬于OO思維。Domain Model比較難使用，一旦習慣，你能夠組織更復雜的邏輯，你的思想會更OO。到時候，即使是小的系統，你也會自然的使用Domain Model了。
　　
　　但如何抉擇呢？假如邏輯復雜，那肯定用Domain Model：假如只需要存取數據庫，那Transation Script會好一些。但是需求是在不斷進化的，你很難保證以后的需求還會如此簡單。假如你的團隊不善于使用Domain Model，那你需要權衡一下投入產出比。另外，即使是Transation Script，也可以做到把邏輯和基礎架構分開，你可以使用Gateway。
　　
　　對例2，毫無疑問要使用Domain Model。對例1就需要權衡了。而對于例3，你很難說它將來會不會像例2那樣，你現在可以使用Transation Script，但未來你可能要使用Domain Model。所以說，架構的決策是至關緊要的。
　　
　　除了這兩種模式，還有其它中庸的模式。Use Case Controller就是處于兩者之間。只有和單個的用例相關的業務邏輯才放到對象中。所以大致上他們還是在使用Transation Script，而Domain Model只是Database Gateway的一組集合而已。我不太用這種模式。
　　
　　Table Module是另一個中庸模式。很多的GUI環境依托于SQL查詢的返回結果。你可以建立內存中的對象，來把GUI和數據庫分開來。為每個表寫一個模塊，因此每一行都需要要害字變量來識別每一個實例。
　　
　　Table Module適用于很多的組件構建于一個通用關系型數據庫之上，而且領域邏輯不太復雜的情況。Microsoft COM 環境，以及它的帶ADO.NET的.NET環境都適合使用這種模式。而對于java，就不太適用了。
　　
　　領域邏輯的一個問題是領域對象非常的臃腫。因為對象的行為太多了，類也就太大了。它必須是一個超集。這就要考慮哪些行為是通用的，哪些不是，可以由其它的類來處理，可能是Use Case Controller

上一篇：線程堆：給你的線程命名，察看你的系統

下一篇：使用JMS在集群應用程序中分配任務(圖)