Session Facade 的規(guī)則和模式（1）

2019-11-18 14:18:00

字體：大中小

供稿：網(wǎng)友

　　session Facade 的規(guī)則和模式（1）

在過去幾年中，EnterPRise javaBeans™（EJB）確實已經(jīng)開始對 Java™ 對象設(shè)計產(chǎn)生影響。期間，我們看到的最常使用的 EJB 模式之一是Session Facade 概念。這是一個讓很多開發(fā)者都受益匪淺的既強大又非常簡單的概念。然而，我也看到，對這一模式的確切含義及其在實踐中的應(yīng)用，人們?nèi)杂泻芏嗾`解。

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

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

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

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

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

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

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

Facade 模式的要點

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

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

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

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

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

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

下一篇：ramdom的應(yīng)用