CowNew開源團隊

Session Fa?ade 模式

? 在 J2EE 項目中 DTO 模式常常是與 Session Fa?ade 模式協作使用的。為了執行一個業務邏輯，經常需要訪問多個服務器端對象（典型的是實體 Bean ）。這樣出現的問題就是多個細粒度的對會話 Bean 和實體 Bean 的調用增加了多個網絡調用的開銷，而且還有一個問題就是業務邏輯被“下放”的客戶端，系統的可維護性降低。

比如我們要修改一個托運協議單，我們首先要找到這個托運協議單，然后對其進行修改，（其中還要請求托運協議單明細，并對托運協議單明細進行修改），然后把修改后的結果發送到服務器。如下圖所示：

??? 在一次業務中客戶端要與服務器進行四次網絡調用。而且實體 Bean 都是具有事務性的，所以每個調用都會在服務器端產生一個獨立的事務。而且更加糟糕的是，由于每個對 EntityBean 的調用都是一個獨立的事務，那么如果在 updateConsignBillMaster 之后， updateConsignBillDetail 的時候發生了錯誤，那么就會造成數據的不一致，違反了事務的原子性。

可見這種方式有如下的缺點：

① 高昂的網絡調用開銷

② 耦合性太高。客戶端是根據服務器端的EntityBean的結構寫的，如果服務器端發生了改變的話，也必須同時修改客戶端。

③ 復用性不好。修改托運協議單的業務邏輯被寫到了客戶端，如果以后我們要將UI由jsp網頁改成applets、或通過Power Builder等開發工具開發前臺界面等的時候，這些業務邏輯代碼就必須再此重寫。

④ 開發人員無法合理分工。在大型項目中，一般都是將表示層（jsp/servlet）、業務層（Session Bean）和持久層（Entity Bean）等由不同的程序員來完成。如果采用我們上邊提到的方法的話，表示層開發人員也必須同時理解業務層和持久層的實現方式，這樣加大了開發的復雜度和比較高的出錯率。

⑤ 無法保證業務的事務性。

我們采用Session Fa ? ade模式解決這個問題：我們將實體Bean包裝在會話Bean中，客戶端只能訪問會話Bean和不能直接訪問實體Bean。

采用這種模式后，客戶端和服務器的交互將會是這樣的：