Session Facade 的規則和模式（1）

2019-11-18 14:18:00

字體：大中小

來源：轉載

供稿：網友

　　session Facade 的規則和模式（1）

在過去幾年中，EnterPRise javaBeans™（EJB）確實已經開始對 Java™ 對象設計產生影響。期間，我們看到的最常使用的 EJB 模式之一是Session Facade 概念。這是一個讓很多開發者都受益匪淺的既強大又非常簡單的概念。然而，我也看到，對這一模式的確切含義及其在實踐中的應用，人們仍有很多誤解。

為了把這個問題講得更明白些，我會在本文中講述 Facade 的一些基本概念以及Session Facade 模式的工作機制，并探討該模式衍生出來的一些問題。希望能借此澄清一些誤解，并幫助開發者正確使用這種模式。

什么是Session Facade？您又為什么需要它？

很多地方都有對Session Facade 模式的清楚描述，也就是 [Sun 2001] 和 [Brown 2000]。我不想照抄那里的全部內容，而打算把它的理論在此作個總結：基本的問題是在 EJB 設計中，EJB 客戶機（例如，Servelet、Java 應用程序，等等）不可直接訪問 Entity bean。

之所以如此，有以下幾個原因：

當依靠 RMI-IIOP 進行跨越網絡的調用時運行態的性能會受到極大影響。假如客戶機請求一個Entity bean 去表示如包含兩項數據（比方說帳戶余額和帳戶所有者姓名）的銀行帳戶，則將需要兩個網絡調用。當大量屬性使網絡調用成倍增加時，很快這些開銷就會變得非常明顯。[Monson-Haefel] 中所說的批量訪問器（bulk accessors）或許是一種解決方案，所謂批量訪問器，就是Entity bean 上的一些方法，它們創建并返回值對象以表示Entity bean 中的數據。它事實上就是 Java VisualAge® 的 CopyHelper Access Beans 采用的解決方案。但是，它有一個令人遺憾的缺陷，就是它假設所有的請求都需要 EJB 中的“所有”數據，結果為用戶返回了一些不必要的數據，并導致對更大的值對象進行組織和分解時產生額外開銷。

更重要的是，假如您答應 EJB 客戶機直接訪問Entity bean，那么就要求客戶機了解Entity bean 的內部方法，而這已經超出了客戶機的應知的范圍。例如，操作一個Entity bean 需要知道所涉及到的該實體的關系（關聯，繼續），這樣就把業務模型的所有細節不適當地暴露給了客戶機。另外，操作多個Entity bean 會要求使用客戶端事務 ? 這是另一個使事情復雜化的因素，這意味著 EJB 可能要被從客戶機設計中除去，而不是添加上去。
大多數設計師已經發現為了在 EJB 設計中避免直接訪問Entity bean 的解決方案都可以在 [Gamma] 中描述的 Facade 中找到。[Gamma] 這樣描述 Facade 模式：“為子系統中的一套接口提供了一個統一的接口。Facade 定義了一個更高層次的接口，使子系統更輕易使用。”1在 EJB 中應用這種思想一般意味著您應該創建一個擔當 Facade 的Session EJB，然后把構成子系統的一套Entity bean “包裝”起來。這樣，客戶機就和Entity bean 實現的細節分離開來了，而且不必自己治理事務治理的細節。

但問題是有很多人到此就打住了。然后他們輕松地往下做，開始把Entity bean 包裝到Session bean 中，而不考慮 Facade 模式所描述的其它內容以及 EJB 設計中由 Facade 模式衍生出來的問題。這很可能是由于把得到的 Facade 的“二手”信息都當真，而沒去研究原始模式的緣故。假如我們確實花了些時間去理解 Facade 衍生的問題，我們將可以看到很多該模式所固有的其它有益的設計可能性。

Facade 模式的要點

[Gamma] 中描述了很多我們應該了解的 Facade 模式的要點。前面幾點可在 Facade 模式的“適用性”描述部分找到，它描述了在什么情況下您會需要應用該模式。它們是：“當您想為復雜的子系統提供一個簡單接口時……請使用 Facade 模式”和“當您想把子系統分層時……請使用 Facade 模式。使用 Facade 為每一層子系統定義一個入口點。”2

從對 Facade 模式的討論中，我們可以提煉出兩個觀點。第一點是 Facade 應該提供子系統的一個抽象視圖，而不是簡單地把整個子系統本身的 API 直接包裝起來。不幸的是，我在實際中多次看到開發者創建的Session bean 把Entity bean home 和Entity bean 對象的全部方法直接包裝起來，而不提供任何額外的抽象，這是對該模式最可惡的濫用情況之一。請記住，這種思想是想降低整個系統的復雜性，而不是把復雜性轉移到另一個對象上。

第二點，也是更微妙的一點，與分層有關。這個觀點認為您可以用多重 Facade 來隱藏下層子系統的細節。因此，在這里您可以這樣設想，Session Facade 應該在其它 Facade 之上，位于最上層，是對底層業務邏輯細節的進一步抽象。這一點很要害。當您看完下面兩條（分別出自 [Gamma] 中論述 Facade 模式的“協作”和“相關模式”部分）敘述后，就會更加清楚這一點：

“客戶機通過把請求發送給 Facade，再由 Facade 把請求轉發給適當的子系統對象來與子系統通信。”3
“facade 只是對通往子系統對象的接口進行抽象以使它們更易于使用；它不定義新功能。”4
我把這幾點總結如下：Facade 不做系統的實際工作；而是委托其他對象輪流做這個工作。由此推理出您必須正確地放置這些對象，以便使該模式能按照您所期望的運行。

這一點是本模式的兩種流行表達 [Sun 2000] 和 [Sun 2001] 之間的主要不同之處。第一個版本，即 [Sun 2000]，是 J2EE 規劃的一部分，它把這種模式稱為“Session Entity Facade”。它意在表明“為一堆企業 beans 提供單一的接口”。它描述了這樣一種模式，即所有的數據存取都通過Entity bean 來完成，Session bean 則為這些Entity bean 提供接口。現在的問題是 [Sun 2000] 不一定非要以 EJB 為中心。它根本不涉及其它對象類型，并且假設系統中只有 EJB 一類對象。根據我的經驗，我認為這會導致根本不能在工程間重用的臃腫的Session對象，而且，在同一個工程內，當需求有一點不同時就會出現問題。

上一篇：Servlet的圖象處理技巧

下一篇：ramdom的應用