J2EE的Web和企業(yè)架構(gòu)（WEA）設(shè)計(jì)模式之一

2019-11-18 16:21:26

字體：大中小

供稿：網(wǎng)友

標(biāo)題：j2ee的web和企業(yè)架構(gòu)（wea）設(shè)計(jì)模式之一
作者：        Ganesh PRasad, Rajat Taneja and Vikrant Todankar
翻譯：        javaduke（Matrix ID）
                  Email:javaduke@263.net
                  QQ:658155
                  MSN:javaduke@hotmail.com

譯者注：第一次接受翻譯任務(wù)，由于能力和時(shí)間有限，可能有很多地方翻譯的不恰當(dāng)或者翻錯(cuò)，歡迎大家指正。歡迎給我來信告知。Email:javaduke@263.net。工作QQ:658155

編者注：在這篇文章中，編者打算提出下面五類模式：劃分（partitioning）,作用域（scope）,安全（security），導(dǎo)航（navigation）和數(shù)據(jù)量控制（data Volume Control）。由于篇幅的限制，我們把文章劃分為兩部分。第一部分，闡述劃分和范圍模式。第二部分，將講解剩下的三類模式。

        由于GoF（Gamma, Helms, Johnson, and Vlissides）的設(shè)計(jì)模式的廣發(fā)普及，軟件工程專家們找到了一個(gè)新的強(qiáng)有力的設(shè)計(jì)方法。什么是設(shè)計(jì)模式？他們這樣定義：“設(shè)計(jì)模式就是描述一個(gè)反復(fù)出現(xiàn)的問題，以及解決這個(gè)問題的方案的核心。你可以重復(fù)使用這個(gè)解決方案而無須再做重復(fù)勞動(dòng)。”一般來說，一個(gè)設(shè)計(jì)模式包括四個(gè)基本要素：模式名稱，需要解決的問題，解決方案和使用帶來模式的效果（或后果）。
        在GoF中描述的設(shè)計(jì)模式,諸如Factory Method, Observer, Façade等，在現(xiàn)在的應(yīng)用設(shè)計(jì)領(lǐng)域已是人人皆知，家喻戶曉。正像編者在先前說的那樣，設(shè)計(jì)模式的命名與描述和一樣起著相當(dāng)重要的作用。在設(shè)計(jì)會(huì)議中人們使用設(shè)計(jì)模式的命名比使用他們枯燥乏味的描述節(jié)省工作量是可以用人小時(shí)估算出來的。
        這本書出版七年以后，我們發(fā)現(xiàn)設(shè)計(jì)模式大致和從前是相對(duì)一致的。盡管后來也有人增加了一些設(shè)計(jì)模式，但遠(yuǎn)遠(yuǎn)不及起初GoF的提出設(shè)計(jì)模式集合價(jià)值高。經(jīng)試驗(yàn)證明，沒有一個(gè)設(shè)計(jì)模式能達(dá)到最初的那23種設(shè)計(jì)模式的普及和聲望。借用經(jīng)濟(jì)學(xué)的一個(gè)術(shù)語來說就是，新的模式的邊際效用幾乎趨近于零。因此設(shè)計(jì)模式科學(xué)是無非是一個(gè)一次性思想的靜態(tài)集合。
        正相反，從一個(gè)Web領(lǐng)域應(yīng)用程序設(shè)計(jì)者的經(jīng)驗(yàn)來講，我們發(fā)現(xiàn)一些歷史經(jīng)驗(yàn)（如果你愿意也可以叫模式）事實(shí)上是無法實(shí)施在應(yīng)用程序級(jí)或子系統(tǒng)級(jí)上實(shí)現(xiàn)一套指定的方法集這樣的需求，同樣的方式，最初的設(shè)計(jì)模式就能完成這種低級(jí)別功能標(biāo)準(zhǔn)化的需求。
        接下來我們討論的內(nèi)容其實(shí)也不是什么新東西。它們是一些許多有經(jīng)驗(yàn)的開發(fā)人員所知道的并經(jīng)常使用的簡(jiǎn)單，標(biāo)準(zhǔn)，通用的方法。仿照最初設(shè)計(jì)模式集的方式，我們對(duì)這些顯而易見的方法分類和命名，希望可以使用這些命名（通過生動(dòng)地捕捉這些方法的基本功能獲得的）來證明它們是非常有價(jià)值的。我們把它們命名為“Web和企業(yè)架構(gòu)設(shè)計(jì)模式（Web and Enterprise Architecture Design Patterns）”，簡(jiǎn)稱“WEA設(shè)計(jì)模式”一個(gè)應(yīng)用程序級(jí)的設(shè)計(jì)模式的宏觀命名。
        作為一個(gè)J2EE的熱衷者，我們僅僅關(guān)注與Java相關(guān)的問題和解決方案上，盡管這樣，許多概念對(duì)其他技術(shù)也還是相當(dāng)有幫助的。（難道設(shè)計(jì)模式不是獨(dú)立于語言的嗎？這是一個(gè)相當(dāng)吸引人的想法，但是確實(shí)存在爭(zhēng)論，如GoF的模式Abstract Factory and Prototype對(duì)C++和SmallTalk是非常有用的，而對(duì)Java來說是多余的。因?yàn)镴ava的Class類和類的反射機(jī)制非常好的解決了這些問題。）

wea設(shè)計(jì)模式的分類和注意事項(xiàng)
        回想GoF，它把設(shè)計(jì)模式分為三類，通俗易懂，便于記憶：創(chuàng)建（Creational）,結(jié)構(gòu)（StrUCtural）, 和行為（Behavioral）。
        秉承這一優(yōu)良傳統(tǒng)，我們把我們的模式分為劃分（Partitioning）,作用域（Scope）,安全（Security），導(dǎo)航（Navigation）和數(shù)據(jù)量控制（Data Volume Control）五類。這并不是一個(gè)詳盡列表，而僅僅是最初的感覺比較適當(dāng)?shù)哪Ｊ筋愋图?br />
模式描述
        我們粗略地使用GoF建立的描述結(jié)構(gòu)來描述我們的模式。為了簡(jiǎn)便，我們將壓縮處理為三個(gè)大標(biāo)題。在“意圖（Intent）”標(biāo)題下，我們用一行陳述使用這個(gè)模式的意圖。我們?cè)凇皢栴}和方案（Problem and Solution）”標(biāo)題下闡述要解決的問題及其解決方案。最后，我們?cè)凇靶Ч–onsequences）”標(biāo)題下詳盡論述使用此模式帶來的積極和消極的因素。
        為了簡(jiǎn)潔，我們也省去UML類圖描述。我們的模式是相當(dāng)簡(jiǎn)單，并不需過多的描述。我們也省去了Java代碼樣例。我們相信大多數(shù)J2EE開發(fā)人員都能明白這些模式。

劃分模式（partitioning Patterns）
        在應(yīng)用程序中，客戶端（瀏覽器）和服務(wù)器都能執(zhí)行邏輯，客戶端通過javascript完成，服務(wù)器通過服務(wù)器端腳本語言如Java或php執(zhí)行。但由于各種原因應(yīng)該把這兩個(gè)層中應(yīng)用程序邏輯分開。

1．        啞客戶端（dumb Client）

意圖（intent）
不用客戶端（瀏覽器）執(zhí)行應(yīng)用程序邏輯。
問題和方案（problem and Solution）
許多應(yīng)用程序采取一種避免使用Javascript的策略。一個(gè)非常普遍的原因就是當(dāng)用戶
當(dāng)關(guān)掉瀏覽器的支持JavaScript功能時(shí)，應(yīng)用程序就不能正常的運(yùn)轉(zhuǎn)了。還有就是開發(fā)人員開發(fā)時(shí)還需要考慮對(duì)瀏覽器不同版本的支持。（盡管現(xiàn)在許多瀏覽器都改善了對(duì)w3c的兼容，但是這種考慮并沒有消除）
        如果有這些的原因其中一種，我就必須把所有的處理放到服務(wù)器上完成。即使是非常簡(jiǎn)單的屬于前臺(tái)的，而且使用JavaScript非常容易實(shí)現(xiàn)的操作也要放到服務(wù)器上執(zhí)行。例如，許多電子商務(wù)應(yīng)用程序在服務(wù)器端計(jì)算總數(shù)，盡管計(jì)算所需的信息都在客戶端。
效果（consequences）
使用啞客戶端模式給應(yīng)用程序帶來的好處就是可以在任何版本瀏覽器上運(yùn)行，包括老以
前的版本。可以相當(dāng)好的支持安全要求，不允許用戶執(zhí)行任何客戶端腳本。
        使用這個(gè)模式的短處就是增加了網(wǎng)絡(luò)傳輸和服務(wù)器的負(fù)載。這可能對(duì)應(yīng)用程序的性能造成不良的影響，盡管這種影響我們可以在用例級(jí)精確地評(píng)測(cè)出來。除此之外，許多操作不支持本地執(zhí)行之后，操作會(huì)變得粗糙不流暢，使應(yīng)用程序交互性變差，不友好。

2．        獨(dú)立客戶端（independent Client）

意圖（intent）
        使用交互接口提高客戶端和服務(wù)器的執(zhí)行能力
問題和方案（problem and Solution）
        現(xiàn)在大多數(shù)Web應(yīng)用程序都是客戶端和服務(wù)器都需處理邏輯的智能混合體。客戶端使用Javascript執(zhí)行本地的表單驗(yàn)證來提高交互能力，服務(wù)器執(zhí)行一些需要和后臺(tái)交互的請(qǐng)求的處理。客戶端和服務(wù)器代碼單獨(dú)編寫，這樣可能造成在兩個(gè)層中一定程度的代碼冗余。
效果（consequences）
        使用獨(dú)立客戶端模式的優(yōu)點(diǎn)就是使應(yīng)用程序更自然，更舒服。許多操作可以不和服務(wù)器交互在很短的響應(yīng)時(shí)間內(nèi)就完成。網(wǎng)絡(luò)傳輸降到最小，服務(wù)器負(fù)載降到最小。
        使用此模式的缺點(diǎn)就是使兩個(gè)層之間邏輯代碼造成冗余。例如客戶端的驗(yàn)證要比服務(wù)器端的驗(yàn)證更友好，因?yàn)樗母捉o用戶快速反饋。但它并不能代替服務(wù)器端驗(yàn)證，因?yàn)楹笈_(tái)并不能依靠前臺(tái)驗(yàn)證，后臺(tái)必須執(zhí)行自己的驗(yàn)證來保證不被錯(cuò)誤數(shù)據(jù)侵害。這種冗余可能會(huì)造成異常和錯(cuò)誤，尤其是在維護(hù)階段邏輯發(fā)生變化的時(shí)候。由于Java和JavaScript的差異很可容易使我們掉入陷阱。

3．        改良服務(wù)器客戶端（server-modified Client）

意圖（intent）
        通過少量服務(wù)器端處理來提供高級(jí)的客戶端交互。
問題和方案（problem and Solution）
        有時(shí)，客戶端的處理需要一些存儲(chǔ)在數(shù)據(jù)庫或后臺(tái)的數(shù)據(jù)。應(yīng)用程序可以預(yù)先把這些數(shù)據(jù)取出來放到一個(gè)數(shù)據(jù)結(jié)構(gòu)中，當(dāng)JavaScript需要時(shí)，就可以輕松的訪問這個(gè)數(shù)據(jù)結(jié)構(gòu)，而不需要每次都去和服務(wù)器交互一次。這樣一旦一個(gè)頁面被載入，客戶端操作就可以迅速的訪問他想要訪問的數(shù)據(jù)了。例如，動(dòng)態(tài)和有條件的裝配一個(gè)下拉框，JavaScript就可以訪問使用從后臺(tái)數(shù)據(jù)庫獲得數(shù)據(jù)組裝成的一個(gè)數(shù)組完成。
        一些更復(fù)雜的應(yīng)用程序可能需要后臺(tái)來生成JavaScript函數(shù)。例如，用服務(wù)器控制客戶端驗(yàn)證。
        改良服務(wù)器客戶端模式目的是為了處理JavaScript代碼和使用Web層Java代碼數(shù)據(jù)結(jié)構(gòu)的變化。并不是用于生成Html元素，那是jsp的基本功能。（當(dāng)然，灰色域也是一種隱式商業(yè)邏輯，如有條件生成的HTML導(dǎo)航元素）
效果（consequences）
        使用改良服務(wù)器客戶端模式的優(yōu)勢(shì)就是，在沒有冗余的情況下達(dá)到良好交互。使在一點(diǎn)控制客戶端和服務(wù)器端邏輯成為可能。兩個(gè)層之間的異常得以減少或消除。
        使用這一模式的劣勢(shì)在于增加了復(fù)雜度。因?yàn)樯蒍avaScript代碼是相對(duì)簡(jiǎn)單，而維護(hù)生成這些代碼的代碼，復(fù)雜程度一般會(huì)增加一個(gè)數(shù)量級(jí)。

作用域模式（scope Patterns）
        作用域一般指一些信息的生命周期，經(jīng)驗(yàn)告訴我們，我們遇到的作用域有下面幾種：請(qǐng)求（Request）、會(huì)話（session）和關(guān)系（Relationship）。
        一個(gè)請(qǐng)求作用域變量在客戶端請(qǐng)求返回之前都是可以訪問的。一個(gè)會(huì)話作用域變量從用戶登陸到會(huì)話未結(jié)束之前一直可以訪問。最后，一個(gè)關(guān)系作用域變量，只要在應(yīng)用程序中存在這個(gè)用戶的詳細(xì)資料，這個(gè)變量就一直存在。關(guān)系作用域并不是JSP規(guī)范定義的一種作用域類型，而是根據(jù)現(xiàn)實(shí)中抽象出來的，諸如個(gè)性化。（我們并不去過多考慮JSP定義的Page和application這兩個(gè)作用域）

4．        請(qǐng)求訪問器

意圖（intent）
        在多步驟的服務(wù)器端處理中，提供對(duì)請(qǐng)求作用域變量的統(tǒng)一訪問的機(jī)制。
問題和方案（problem and Solution）
        大多數(shù)Web開發(fā)的初學(xué)者會(huì)發(fā)現(xiàn)JSP的一個(gè)殘酷而又明顯的缺陷之一就是沒有一個(gè)像HttpServletRequest對(duì)象的getParameter()方法一樣的設(shè)置器。這樣就可能使請(qǐng)求在組件間傳來傳去時(shí)，在Web層進(jìn)行一系列操作變得特別頭疼。有些操作可能還需要請(qǐng)求作用域變量進(jìn)行修改，而缺少setParameter()方法，這將會(huì)變得極其糟糕。
        請(qǐng)求對(duì)象的用于處理指定對(duì)象的getAttribute()(與getParameter()方法相比，它將返回一個(gè)指定字符串)和setAttribute()給了我們一線希望。可是，使用getAttribute()方法從一個(gè)新來自瀏覽器請(qǐng)求對(duì)象中獲得參數(shù)是無效的，還必須調(diào)用getParameter()方法。
        請(qǐng)求訪問器模式被設(shè)計(jì)為，使用一個(gè)兼容的接口來對(duì)請(qǐng)求對(duì)象的檢索、存儲(chǔ)和重檢索進(jìn)行管理。更簡(jiǎn)單的說，這個(gè)模式就是，工具類的一個(gè)靜態(tài)方法（可以叫g(shù)etAttributeOrParameter()方法），用于查找指定的HttpServletRequest對(duì)象。先調(diào)用getAttribute()方法，如果什么都沒找到，就調(diào)用getParameter()方法。任何需要檢索請(qǐng)求作用域的服務(wù)器端組件都可以使用這個(gè)方法。可以就迅速的一次性訪問到從瀏覽器傳來得參數(shù)。當(dāng)這個(gè)變量是被改變了又放到請(qǐng)求對(duì)象中的話，必須先調(diào)setAttribute()方法，然后，再調(diào)用請(qǐng)求訪問器，就可以找到最新的被修改過的參數(shù)，而不是最初的原始數(shù)據(jù)。由于被傳過來的參數(shù)都是字符串，而所有的字符串都是對(duì)象，當(dāng)要檢索的對(duì)象時(shí)，只要在請(qǐng)求訪問器找到后，對(duì)字符串進(jìn)行造型就可以了。
（在multi-part類型的表單中，當(dāng)請(qǐng)求從一個(gè)傳到另一個(gè)組件時(shí)，請(qǐng)求對(duì)象可能被扔掉并重造，過程相當(dāng)復(fù)雜。這樣導(dǎo)致所有的請(qǐng)求作用域的變量被丟失。例如，在這種情況就可以使用session對(duì)象（小心使用！！）把請(qǐng)求作用域變量傳給組件。請(qǐng)求訪問器也必須考慮到這種情況的方法。）
效果（consequences）
使用請(qǐng)求訪問器模式的優(yōu)遇就是提供一個(gè)在服務(wù)器端多步驟處理中訪問請(qǐng)求作用域變量的簡(jiǎn)單方法。例如Struts。
        使用這一模式的缺憾就是要盡量避免使用屬性名而帶來的沖突。

5．        無狀態(tài)通道

意圖（intent）
        把應(yīng)用程序的狀態(tài)管理從以Web為中心的機(jī)制中獨(dú)立出來。
問題和方案（problem and Solution）
        大多Web應(yīng)用程序?qū)ession的狀態(tài)維護(hù)都是使用JSP引擎的隱式session對(duì)象來保存會(huì)話作用域變量的。盡管這樣，多通道應(yīng)用程序還是盡可能避免和以Web為中心的機(jī)制纏在一起。人們更喜歡來維護(hù)客戶端和應(yīng)用程序服務(wù)期間點(diǎn)對(duì)點(diǎn)的狀態(tài)。使中間Web層（JSP引擎）保持無狀態(tài)。這個(gè)方式使增加通道變得更加容易（例如IVR（Interactive Voice Response）-交互聲音響應(yīng)），而無需復(fù)制維護(hù)狀態(tài)邏輯。也有利于避免Web會(huì)話和物理JSP引擎之間的耦合。使Web層水平負(fù)載平衡方案更加容易實(shí)現(xiàn)，使用一個(gè)循環(huán)實(shí)現(xiàn)而不是使用簇。（簇相對(duì)而言是一個(gè)比較新的技術(shù)，好多舊的JSP引擎并不支持。）
        無狀態(tài)通道模式利于多通道應(yīng)用程序中會(huì)話作用域變量的管理。當(dāng)驗(yàn)證成功之后，應(yīng)用程序服務(wù)器產(chǎn)生一個(gè)會(huì)話符號(hào)串，通過Web層傳到客戶端（如瀏覽器），Web層并不存儲(chǔ)會(huì)話符號(hào)串，在HttpSession對(duì)象也不存，其他任何地方都不存儲(chǔ)會(huì)話符號(hào)串。客戶端（瀏覽器）使用表單隱藏變量的形式或在一個(gè)超級(jí)鏈接中的一個(gè)get參數(shù)來暫存會(huì)話符號(hào)串，這樣，當(dāng)表單提交或鏈接被使用時(shí)，會(huì)話符號(hào)串會(huì)被傳回Web層，Web層就可以處理它，（本地并不存儲(chǔ)它），接著被傳回到應(yīng)用程序?qū)域?yàn)證，并檢索會(huì)話作用域變量（和關(guān)系作用域變量）。這樣，會(huì)話狀態(tài)就被點(diǎn)對(duì)點(diǎn)維護(hù)，一種與通道完全獨(dú)立的方式。因此命名為無狀態(tài)通道。
效果（consequences）
        使用無狀態(tài)通道模式的最大優(yōu)點(diǎn)就是可以不必給每個(gè)通道層重新開發(fā)狀態(tài)管理就可以建立多通道應(yīng)用程序。也可以通過簡(jiǎn)單的負(fù)載平衡方案（如循環(huán)）來實(shí)現(xiàn)一個(gè)具有水平比利縮放能力的通道層。
        使用這一模式的主要缺點(diǎn)是增加了復(fù)雜度，還有使用會(huì)話對(duì)象時(shí)為避免沖突而進(jìn)行的額外需求。一個(gè)純粹的Web開發(fā)者可能很難習(xí)慣這種方式。

編者注：下周我們將結(jié)束web和企業(yè)架構(gòu)設(shè)計(jì)模式這個(gè)主題。編者將闡述剩下的三類模式：
安全（Security）、導(dǎo)航（Navigation）和數(shù)據(jù)量控制（Data Volume Control）。

作者簡(jiǎn)介：
Ganesh Prasad：        澳大利亞第三大銀行Westpac Banking Corporation的架構(gòu)師。
Rajat Taneja：           Sun公司澳大利亞負(fù)責(zé)人。
Vikrant Todankar：澳大利亞EDS高級(jí)顧問，
被指派到澳大利亞第二大銀行the Commonwealth Bank of Australia。進(jìn)入討論組討論。

（出處：http://m.survivalescaperooms.com）

上一篇：j2ee設(shè)計(jì)模式：CMP到BMP模式（一）

下一篇：J2EETM藍(lán)圖摘要