導讀：從JDK 5.0開始 J2EE 改名為 Java EE弦悉。 Java EE被企業(yè)廣泛使用，必然有其可取之處，甚至可以說Java EE這門技術造就了不少優(yōu)秀的程序員昂芜。

第1章：導論别伏。

模式能夠：

利用一個經過驗證可行的解決方案蹄衷；

提供一套通用詞匯；

約束解決方案的空間厘肮。

第2章：表現(xiàn)層設計考慮和不佳實踐愧口。

客戶端驗證：基于表單的驗證、基于抽象類型的驗證类茂。

曾經在JSP中濫用過的助手類耍属，通過助手類在頁面和業(yè)務邏輯之間傳遞數(shù)據(jù)，有點類似于如今Struts中的Action作為傳值模型時的情況巩检。

表現(xiàn)層不佳實踐：

多個視圖中都包含控制代碼厚骗；

表現(xiàn)層數(shù)據(jù)結構暴露給業(yè)務層或者業(yè)務領域對象，比如：暴露HTTPServletRequest兢哭；

重復提交表單领舰；

敏感資源暴露給客戶端直接訪問，有個原則迟螺，敏感的東西不能放在WEB-INF之外提揍；

胖控制器；

……

怎么區(qū)分后臺視圖層和前臺頁面層煮仇？或者說，怎么劃分哪些事情JSP或者模板做谎仲，哪些事情JavaScript做浙垫？首先，根據(jù)模型驅動的原則郑诺，通常送到JSP或者模板上的都是通用模型的對象或者對象集夹姥，JSP或者模板根據(jù)需要選擇展示出來，但是后續(xù)可抽取為不需和服務端交互狀態(tài)下響應用戶的行為辙诞，應當劃分為JavaScript的工作辙售。

第3章：業(yè)務層設計考慮和不佳實踐：

session bean：根據(jù)EJB規(guī)范，每個session bean專門服務于一個客戶端或者用戶飞涂，生命時間等于客戶端會話時間旦部；在服務器崩潰后無法存活、無法持久化较店、會超時士八、可以涉及事務；支持構造有狀態(tài)或無狀態(tài)的對話模型梁呈。

不過現(xiàn)在的容器會話大多可以持久化了婚度，會話復制和會話持久化應當是會話管理中重要的兩個分支，通常情況下會話不需考慮完整的事務性官卡，保證線程獨立性即可蝗茁。

至于無狀態(tài)的session bean醋虏，可以被池化，以高效利用（EJB容器管理）哮翘。

entity bean：實體bean是否應該包含業(yè)務邏輯颈嚼？按照下面三個原則去判定，還是比較清晰的：

這樣的業(yè)務邏輯是否會引入實體之間的關系忍坷？比如處理UserInfo的時候粘舟，是否引入了AccountInfo，這樣應當考慮根據(jù)模型驅動的原則佩研，放置到專門的User或者Account相關的業(yè)務無狀態(tài)bean中去柑肴；

是否要負責管理用戶交互的工作流？

是否會擔負起本該屬于其他業(yè)務組件的責任旬薯？

有一個“是”晰骑，就說明不該包含這段業(yè)務邏輯。

尤其提一句绊序，如果使用遠程實體bean硕舆，就更應該減少實體bean之間的依賴關系，以提高性能和可用性骤公。

業(yè)務層和集成層不佳實踐：

對象模型或關系模型或每個用例直接映射成實體bean：導致粒度過細抚官，EJB就給網絡傳輸帶來太多的負擔；

通過getter阶捆、setter暴露EJB所有屬性：這也是不好的凌节，提供少量和可控的方法調用，減少遠程方法調用的開銷洒试；

客戶端中包括服務尋址代碼：尋址這件事情應當從單純的客戶端抽離出來倍奢，把不同的尋址策略和復雜度封裝起來，真正做到透明傳輸（擴展到without EJB的系統(tǒng)中也一樣垒棋，集群環(huán)境中也一樣卒煞，把尋址的行為隱藏于業(yè)務邏輯之下）。

EJB用戶長時間持續(xù)的事務：會鎖住其他EJB需要的資源叼架；

……

第4章：J2EE重構：

對業(yè)務層隱藏表現(xiàn)細節(jié)：對用戶請求的處理和通信協(xié)議相關的數(shù)據(jù)不應當被業(yè)務層獲取畔裕，最簡單的例子就是HttpServletRequest對象。

用session bean包裝entity bean：現(xiàn)在這里說的問題一般不會出現(xiàn)碉碉，一般也不會有人直接把Action對象扔給后面的業(yè)務邏輯去處理柴钻，原文說的解決辦法是引入業(yè)務代表，涉及到此的還有兩條：減少entity bean之間的通信垢粮；將業(yè)務邏輯移至session bean贴届。

分離數(shù)據(jù)訪問代碼：DAO。

按層重構系統(tǒng)架構（這里也正好歸納一下現(xiàn)在J2EE系統(tǒng)中常涉及到的Action、Service和EJB中的幾種bean的內在聯(lián)系）毫蚓，例如：

客戶端層：瀏覽器

表現(xiàn)層：JSP占键、模板、業(yè)務代表

業(yè)務層：entity bean（Action）元潘、session bean（各種粒度的Service）

集成層：DAO

資源層：DB

……

表現(xiàn)層模式：

攔截過濾器：Intercepting Filter畔乙。正如圖中的“Apply zero or more”和Servlet規(guī)范所述一樣，應當具備一個鏈式結構翩概。這個鏈式結構中的每個filter牲距，互相之間應當是一個互不依賴的松耦合關系，以便于容易地組合钥庇。

前端控制器：Front Controller牍鞠。給表現(xiàn)層請求安排一個集中訪問點。集中了控制邏輯评姨，一定程度避免了重復代碼难述。和攔截過濾器的區(qū)別：攔截過濾器使用的是松耦合的，結合成鏈式的處理器邏輯吐句，適合進行強大的預處理胁后、后處理的策略分布；而前端控制器則專注于集中控制嗦枢，減少視圖中的業(yè)務和處理邏輯攀芯，提高重用度。

在常用的Struts網站構架中文虏，N個攔截器都是可以自由組合的敲才，也可以自定義合適的攔截器棧來繼承某個通用的基礎攔截器棧，一些通用的攔截邏輯變放置在基礎攔截器棧中择葡，這里是一個攔截過濾器和前端控制器結合實現(xiàn)的例子。

Context對象：不想在與協(xié)議無關的環(huán)境上下文中使用針對特定協(xié)議的系統(tǒng)信息剃氧。就是說系統(tǒng)信息敏储，比如請求、配置和安全數(shù)據(jù)等等朋鞍，這些東西已添，通常應當被隱藏起來，不能被業(yè)務邏輯看到滥酥；但是在某些情形下更舞，業(yè)務組件可能又必須用到這些信息，例如坎吻，進行終端適配的組件缆蝉，需要用到HTTP報文中的一些header，那么直接使用會導致組件的靈活性和可重用性的下降，導致前一篇我提到的表現(xiàn)層數(shù)據(jù)結構和業(yè)務層的緊耦合刊头。

解決方法就是制定一個特定的API黍瞧，將業(yè)務組件需要的部分通過API來包裝和篩選，而不是直接把表現(xiàn)層數(shù)據(jù)結構直接暴露給它原杂。這樣一來印颤，對于表現(xiàn)層的一些改變，比如協(xié)議等方面的改變穿肄，不會直接影響到業(yè)務組件的接口和運行年局，只需要修正API的實現(xiàn)邏輯。

還有個什么好處咸产？如果我需要測試業(yè)務層的邏輯矢否，因為有了這樣一層特殊的API，我可以把整個表現(xiàn)層mock掉锐朴。

這里有一個應用例子就是RequestContext對象兴喂，API只傳輸這個，而不是具體的某一Request對象焚志，對于復雜的請求層面被隔離掉衣迷，留下一個包裝好的上下文給后面的邏輯。

應用控制器：集中地酱酬、模塊化地進行操作管理和視圖管理壶谒。

操作管理：把輸入請求解析到一個操作（action），讓它處理該請求膳沽。

視圖管理：選定返回給客戶端的視圖汗菜，并把請求分派到這個視圖。

這兩點的應用例子其實就是在struts-xxx.xml里面定義的配置挑社，如同一個路標陨界，對于出入視圖層的數(shù)據(jù)進行方向上的導航。

舉例來說痛阻，它的實現(xiàn)經常采用的策略是command對象的策略菌瘪，命令對象的說法具體可見GoF的那本經典設計模式的書。

效果：把操作管理和視圖管理分離開了阱当，提高了模塊化程度俏扩；再一個這個導航的邏輯被抽取成為一處獨立的配置單獨維護，方便擴展弊添。

視圖助手：View Helper录淡。把視圖和相關處理邏輯分離開。

這里需要先提及兩個重要的階段：視圖準備階段：這是指請求被分配到一個具體的視圖上面油坝；視圖創(chuàng)建階段：視圖根據(jù)從模型中取得的內容來實例化自己嫉戚。

因此使用視圖封裝顯示格式的代碼刨裆，而使用助手封裝視圖處理邏輯。助手在視圖和模型之間充當了一個適配器的角色彼水，同時也會做一些格式邏輯相關的處理崔拥。

一個很好的例子就是各種標簽，包括自定義標簽凤覆，比如一個時間格式化的標簽链瓦，對于一個時間，在不同的環(huán)境下以不同的格式展示盯桦。

視圖助手終究是“視圖”的助手慈俯，它的核心始終是視圖，對于已經生成了的成熟的具備一定模型的數(shù)據(jù)拥峦，試圖助手協(xié)助將它們以某種合適的方式展示出來贴膘，而不應當做復雜或具體的業(yè)務邏輯。

于是這里提出第一點需要注意略号，怎樣把視圖助手和后端的邏輯區(qū)分開刑峡？視圖助手得到的數(shù)據(jù)應當是已經成熟的一定模型化的數(shù)據(jù)，需要做的是僅僅是做一些格式的處理玄柠，對展示效果的修正和增強突梦，并不做任何業(yè)務邏輯的相關事宜。

第二點需要注意羽利，應當把視圖助手和JavaScript區(qū)分開來宫患，前者在服務端完成，后者在客戶端完成：把處理邏輯從頁面中抽取出來这弧，一個重要原因就是要減少在頁面中直接暴露的實現(xiàn)細節(jié)娃闲。在實際開發(fā)中，這二者之間的區(qū)分匾浪，常常帶來困擾皇帮。比如在模板或者JSP中使用if標簽，還是在客戶端使用JavaScript來控制邏輯蛋辈？我建議這里應當有一個區(qū)分的原則：這些邏輯是否屬于客戶端才能決策的頁面展示細節(jié)玲献？如果是，就使用JavaScript來完成梯浪，反之還是應當隱藏到頁面助手中。

復合視圖：Composite View瓢娜。使用由多個原子化的子視圖構成的復合視圖挂洛。特點是組合是可以動態(tài)的，而頁面布局又可以整體控制眠砾，和頁面內容互相獨立虏劲。

有這么幾個常見的例子：Portlet就是一個復合視圖結合的最好例子，主題可以影響到所有視圖的呈現(xiàn)，又是和展示的具體內容沒有關系的柒巫，Portlet可以在服務端做到視圖的聚合励堡，而不把事情遺留到客戶端完成，不涉及瀏覽器跨域的安全性問題堡掏；SiteMesh是一個很適合對頁眉应结、頁腳等頁面通用元素拼裝的框架，比jsp:include標簽優(yōu)雅泉唁；更小維度上鹅龄，標簽的引用也可以認為是視圖的復合。

視圖的復合增進了視圖模塊化和重用能力亭畜，這方面來看是增加了可維護能力扮休；但是另一方面，一個完整的直觀的頁面被拆得七零八落拴鸵，又降低了可維護性玷坠，為了解決這個問題，我覺得對于一個大型Web應用劲藐，一個好的思路是提供一種工具八堡，至少是一個簡易的指導方法，從頁面的某一部分元素快速定位到具體的最小視圖上瘩燥；另外秕重，視圖的復合帶來了服務端拆解和部署的靈活性，但一定也帶來性能損耗厉膀，Portlet聚合尤為明顯溶耘。

還有一個重要的事項是，頁面布局需要和頁面內容相獨立服鹅。一個較大的視圖拆解成若干個小的子視圖凳兵，這些小的子視圖應當具備獨立的展示內容，但是頁面的布局不應當有其中的任一子視圖控制企软，而可以落到某一個整體的主題定義中去庐扫。

服務到工作者：Service To Worker。集中控制權管理和請求的處理仗哨，再把控制權交給視圖之前獲取表現(xiàn)模型形庭。視圖則根據(jù)獲得的表現(xiàn)模型生成一個動態(tài)響應。這個模式是由前端控制器厌漂、應用控制器和視圖助手組合而成的萨醒。具體說：前端控制器集中了訪問視圖的邏輯，然后應用控制器完成了視圖導航苇倡，最后由視圖助手協(xié)助準備了視圖所使用的模型數(shù)據(jù)富纸。

分配器視圖：Dispatcher View囤踩。把視圖本身作為請求的最初訪問點，把業(yè)務處理的邏輯交由視圖完成晓褪。

服務到工作者和分配器視圖是非常類似的兩種模式堵漱，前者以進視圖前的邏輯處理為核心，后者才真正以視圖為核心涣仿。當業(yè)務處理比較簡單勤庐，或者不能合適地通過視圖之外的邏輯來控制時，可以采用分配器視圖模式变过，把控制邏輯放到視圖中埃元。在這種方式下，不代表分配器視圖做了所有的業(yè)務邏輯媚狰，對于數(shù)據(jù)的準備完全可以在進視圖之前完成岛杀，畢竟視圖中完成大量的業(yè)務邏輯通常不是一個優(yōu)秀的解決方案。

一個很好的例子就是頁面集成崭孤，進入集成頁之前準備好集成的子頁面的URL类嗤，到了集成的父頁面中再執(zhí)行拼裝操作，這個行為辨宠，甚至可能被到客戶端才完成遗锣。這種情形下，盡管頁面去做了聚合視圖的事嗤形，但這恰恰是頁面最擅長的行為精偿，比進頁面之前把數(shù)據(jù)準備好、拼裝好再一并寫入頁面要可見和可接受得多赋兵。

業(yè)務層模式：

業(yè)務代表：Business Delegate笔咽。封裝對業(yè)務服務的訪問，隱藏服務層具體實現(xiàn)細節(jié)霹期，主要為降低客戶端和服務層之間的耦合叶组。除了隱藏服務細節(jié)、處理服務異常等基礎功能以外历造，還可以做服務的緩存甩十。業(yè)務代表是客戶端的直接客戶，起到客戶端業(yè)務抽象層的作用吭产，而業(yè)務代表的另一頭侣监，常常連接著會話門面。

比較常用的情況就是在某種遠程連接和業(yè)務處理的基礎上臣淤，使用業(yè)務代表把這些細節(jié)統(tǒng)統(tǒng)包裝起來橄霉，給內部提供的模型也好API也好，都是和外部接口相異的荒典。比如一個系統(tǒng)中對于展現(xiàn)的內容數(shù)據(jù)的同步酪劫，以及訂購、使用等業(yè)務流程寺董，都由SOAP消息載體來協(xié)助完成覆糟，那么封裝起SOAP消息這種底層行為的PCMP模塊，對其上內部組件暴露的都是系統(tǒng)中通用的模型和API遮咖，將SOAP定義的模型和相應的同步滩字、校驗和通知行為等隔離開了。

服務定位器：Service Locator御吞。封裝對服務和組件的尋址麦箍。在系統(tǒng)，尤其是分布式系統(tǒng)中陶珠，服務通常被設置為可插接的挟裂，通過某種方式掛在服務總線上，尋求某服務的行為應當對服務的使用者來說透明揍诽。

某個大型解決方案中诀蓉，某一組件充當SOA中的ESB，承擔了服務定位的角色暑脆，派發(fā)往各個服務不同協(xié)議的請求渠啤，皆可以統(tǒng)一的協(xié)議收攏到該組件中，再由該組件負責以各種方式分發(fā)給不同的服務添吗。

會話門面：Session Facade沥曹。目的有二：控制客戶端對業(yè)務對象的訪問；降低客戶端和細粒度業(yè)務組件訪問的網絡負載碟联。只暴露必要的妓美、粗粒度的服務，并且可以對之在門面內部做好事務玄帕、安全部脚、尋址和記錄等等切面輔助工作。

多數(shù)情況下使用無狀態(tài)的會話門面裤纹，對于客戶端要求也較低委刘，通常只需要單次調用就能完成功能；但也可能需要使用有狀態(tài)的會話門面鹰椒，通常比較復雜锡移，需要涉及會話事務、會話資源的管理和釋放漆际。

和業(yè)務代表的關系：業(yè)務代表在客戶端提供了對會話門面的抽象淆珊，把客戶端的請求分別代理給專門提供特定服務的會話門面。

應用服務：集中奸汇、聚合特定功能施符，提供一個統(tǒng)一的服務層往声，其接口粒度比服務門面細。服務門面通常包括很少戳吝，甚至不包括業(yè)務邏輯浩销，僅僅提供一個簡單和粗粒度的接口。而一些相關的操作听哭，之間具有內聚性慢洋，這就需要某個角色把它們聚合起來。

Facade成為粗粒度的門面的時候陆盘，內部就由多個細粒度的Service組成普筹，這就是會話門面和應用服務之間的關系。舉一個更具體的例子隘马，一個短信息發(fā)送的會話門面太防，提供了消息發(fā)送的一系列功能，內部則包含了若干個應用服務：拼裝消息報文祟霍、消息事務信息持久化杏头、發(fā)送消息。合理地分割和規(guī)劃應用服務是降低會話門面復雜度的有效途徑沸呐。

業(yè)務對象：利用對象模型把業(yè)務數(shù)據(jù)和業(yè)務邏輯分離開來醇王。業(yè)務對象在最前端（客戶端）和最后端（數(shù)據(jù)資源）都會進行業(yè)務數(shù)據(jù)形式的轉化。業(yè)務對象的實現(xiàn)通常有兩種方式：POJO + JDO 或者 Entity Bean + BMP/CMP崭添。業(yè)務對象包含業(yè)務邏輯和業(yè)務狀態(tài)寓娩。

J2EE系統(tǒng)中面向過程向面向對象轉變有時甚至僅僅區(qū)別于最初的一念之差。沒有什么是絕對的事情呼渣，如果業(yè)務非常簡單棘伴，客戶端通過淺淺的顯示層，直接訪問持久層屁置、甚至數(shù)據(jù)資源存儲中業(yè)務數(shù)據(jù)焊夸，整個過程中，其結構都是依據(jù)客戶端所需數(shù)據(jù)的獲取過程來完成的蓝角，是典型的面向過程的實現(xiàn)方式阱穗，沒有什么不合理；但一旦情況復雜了使鹅，你也許希望在系統(tǒng)中設定一些核心的業(yè)務模型揪阶，讓它們來驅動整個服務的提供和流程的運轉，而不再是客戶端無任何包裝的需求患朱，這時候興許就變成了模型驅動下的面向對象行為鲁僚。

復合實體：Composite Entity。結合本地entity bean和POJO，實現(xiàn)業(yè)務對象持久化冰沙。復合實體能夠把一組相互關聯(lián)的業(yè)務對象聚合為粗粒度的entity bean實現(xiàn)侨艾。業(yè)務對象被實現(xiàn)為父對象和從屬對象，從屬對象緊耦合與父對象拓挥，且無法獨立存在或獨立被訪問蒋畜、識別和管理。無論使用遠程對象還是本地對象實現(xiàn)復合實體撞叽，都不應該直接把entity bean暴露給客戶端，而應當封裝在門面里面插龄。

實際我們的項目中愿棋，給內容超市部分，封裝了核心的API均牢，而API的調用傳值糠雨，都是通過復合實體——各種Event完成的。這是一個很好的例子徘跪，就算日后將API擴展成可遠程調用的方法甘邀，性質并未改變。

臟數(shù)據(jù)標示器策略：對復合實體持久化的時候垮庐，如果能判斷哪些從屬對象是臟的松邪，就可以提高持久化性能。

傳輸策略可以考慮單次傳輸整個復合實體哨查，減少網絡交互逗抑；可以結合臟數(shù)據(jù)標示器，只傳輸變化的部分寒亥；可以結合懶加載策略邮府，只傳輸需要的部分。

傳輸對象：Transfer Object溉奕」涌跨層次傳輸多種數(shù)據(jù)元素。有一種簡化遠程對象和遠程接口的方法是加勤，把眾多get/set方法合并成粗粒度的getDate和setData方法仙辟。我們通常希望傳輸對象是簡單和可控的，因此粒度不應過細胸竞，細節(jié)應盡量屏蔽欺嗤，對于接口的定義，應該盡少約束卫枝。

日后我們系統(tǒng)的API擴展必然面臨著復合實體傳輸?shù)那榫臣灞珹PI的遠程調用已漸漸變得廣泛，比如JavaEye支持API調用校赤，使用JSON作為數(shù)據(jù)形式吆玖；我們常用的Blog客戶端也是遵從的簡約的API規(guī)范開發(fā)的筒溃。

傳輸對象組裝器：Transfer Object Assembler。復合傳輸對象的形式構建應用模型沾乘。從各種不同的業(yè)務組件和業(yè)務服務中聚合多個傳輸對象怜奖，并且最后把復合對象返回給客戶端。最大的好處：減少了客戶端和應用模型之間的耦合翅阵。對于不同的傳輸形式歪玲，就并不需要應用模型做任何的改變，搭配不同的傳輸對象組裝器和傳輸策略即可掷匠。

系統(tǒng)的頁面集成中涉及到的會話信息的傳遞滥崩，提供了幾種策略，就涉及到SpringHTTPInvoker傳輸讹语、OSCache傳輸钙皮、本地傳輸和void傳輸?shù)认鄳膶ο蠼M裝器。

值列表處理器：Value List Handler顽决。執(zhí)行查詢短条、緩存結果，并讓客戶端遍歷才菠、選擇查詢結果茸时。基本上相當于封裝了一個游標赋访，共客戶端遍歷操作屹蚊，但是如果這個游標是遠程的，注意可能造成巨大的性能消耗进每。

我們的系統(tǒng)中設計了一個類：PaginationSupport汹粤，用于分頁，其角色便類似于值列表處理器田晚。需要查詢哪一塊區(qū)域的數(shù)據(jù)集合嘱兼，就傳遞相應的游標指令。

集成層模式：

數(shù)據(jù)訪問對象：Data Access Object贤徒。提煉和封裝對持久化存儲介質的訪問芹壕。DAO封裝了數(shù)據(jù)源的實現(xiàn)細節(jié)，總是面向API調用者提供統(tǒng)一的接口接奈。DAO應當被實現(xiàn)為無狀態(tài)的對象踢涌，這樣就可以成為輕量的對象，不需要考慮線程序宦、同步睁壁、緩存等問題，而把這些問題下沉到數(shù)據(jù)層去完成。

以我參與的項目的緩存的使用舉例潘明，模型DAO并不做任何的緩存行為行剂，數(shù)據(jù)庫使用自身的緩存能力，并且在必要時冗余字段钳降，這是基于數(shù)據(jù)粒度的基礎緩存厚宰；到了調用DAO的業(yè)務層面，比如Service層遂填，才進行業(yè)務模型粒度的緩存铲觉，比如緩存某些用戶對象等；而DAO層實現(xiàn)了基礎DAO的約束吓坚，繼承了Spring給DAO封裝的基礎能力备燃，比如事務控制的能力等，所有方法都不使用類狀態(tài)變量凌唬，找不到任何對用戶會話對象訪問的邏輯，也看不到任何java.sql包內的類和對象（尤其是異常）漏麦。

服務激活器：Service Activator客税。用于接收異步請求，由異步請求來觸發(fā)業(yè)務撕贞。JMS監(jiān)聽器是一個常用的實現(xiàn)者更耻，JMS目標通常有兩種，一種是主題捏膨，即Topic秧均，用于點對面的通知；一種是隊列号涯，即Queue目胡，用于點對點的通知。

解決方案中的請求通常都由界面?zhèn)扔|發(fā)链快，因此服務激活器通常被放置在內部部件（例如計費部件）上誉己，計費業(yè)務的請求由展現(xiàn)部件經過總線轉發(fā)給計費部件觸發(fā)計費服務流程。

業(yè)務領域存儲：將持久化邏輯從對象模型中分離出去域蜗。比如最常用的BMP和CMP巨双，無需根據(jù)不同的業(yè)務對象類型建立不同的數(shù)據(jù)庫腳本，只需要維護好業(yè)務領域側的模型配置霉祸，存儲事件是透明的筑累。

業(yè)務領域存儲的實現(xiàn)有很多種方式，比如Grails內部使用規(guī)約配置和Hibernate的持久化管理能力丝蹭，讓存儲的邏輯完全透明慢宗，映射關系的配置和映射表建表和CRUD的sql語句都可以由規(guī)約代替，于是可以不進行任何的映射配置來實現(xiàn)存儲，真正做到透明存儲婆廊。

再比如：上述的關系型數(shù)據(jù)庫下迅细，數(shù)據(jù)庫表和業(yè)務模型是有映射關系的，也就是常說的橫表淘邻；但是也可以使用縱表茵典，實現(xiàn)數(shù)據(jù)模型的任意擴展，這就是一個通過改變存儲方式來實現(xiàn)持久化邏輯完全不依賴于對象模型的例子宾舅。

使用nosql统阿，海量數(shù)據(jù)的存儲可以是稀疏的，水平擴展性筹我、查詢性能優(yōu)異扶平，它減弱了數(shù)據(jù)之間在存儲層面上相互之間的約束。

Web Service中轉：暴露可通過XML和web協(xié)議訪問的服務蔬蕊，并將對服務的請求轉發(fā)給真實的服務組件结澄。通常有許多Web Service是不希望暴露出來的，有時有一些服務又需要聚合起來使用岸夯，這時候就需要Web Service中轉麻献。在使用中轉前的Web Service需要被改造，以支持中轉的接口（例如一個本地接口）猜扮。這個模式和Facade很類似勉吻，只不過它的定位放在了遠程接口上。

微架構：一組被同時使用的模式旅赢，用于實現(xiàn)系統(tǒng)中的一個特定部分（子系統(tǒng)）齿桃。每一個微架構是獨立和內聚的積木塊，由它們構成整個系統(tǒng)的架構煮盼。微架構有多種形式短纵，比如Web Worker工作流。

工作流可以把業(yè)務邏輯和過程邏輯分離開僵控，使得關注點和階段清晰和分散踩娘。本人當前參與的項目是一個較大的Web項目，處于整個解決方案的前端喉祭，但是里面并未明確提及工作流（盡管在解決方案的后端养渴，計費部件和內容管理部件中明確定義和使用了）。首先要說的是泛烙，作為一個展現(xiàn)部件理卑，對于用戶操作的過程中個，并不適合具備過多的用戶交互途徑蔽氨，通常也不會有特別繁雜的業(yè)務邏輯藐唠；但是倘若整個項目的內容使用部分流程過于復雜帆疟，完全可以引入工作流的思想解決問題。

以一個展現(xiàn)系統(tǒng)中播放的內容使用的流程為例宇立，第一次交互行為prePlay踪宠，發(fā)起播放行為，系統(tǒng)給用戶返回一個產品確認頁面妈嘹；用戶確認并發(fā)起第二次交互行為play柳琢，系統(tǒng)給用戶完成訂購操作并生成播放的rtsp鏈接回送給用戶；第三次用戶使用此rtsp鏈接和播放系統(tǒng)交互润脸。這三次主流程的交互中柬脸，所有交互行為都由用戶出發(fā)（這是通常是展現(xiàn)系統(tǒng)的工作流步驟中的特點），并且只有前兩步和展現(xiàn)系統(tǒng)相關毙驯。每一個步驟都具備獨立的攔截器棧倒堕，相應的Action-Service-DAO方法。在某些業(yè)務復雜的系統(tǒng)中爆价，工作流的步驟是可以自定義的垦巴，即用戶可以自行組裝工作流——這樣的定制屬于縱向業(yè)務流程的定制，與橫向的API調用的定制相異铭段。

通常我們使用request-session-application這樣三類容器管理當前數(shù)據(jù)骤宣，但是在request scope（一次交互的數(shù)據(jù)存放）和session scope（用戶會話數(shù)據(jù)存放）對象之間吧雹，還可以引入flash scope（N次交互的數(shù)據(jù)存放，由攔截器管理）和work flow scope（一個完整業(yè)務流程的數(shù)據(jù)存放吨岭，由工作流引起管理）對象聘惦。

好了同學們，我能介紹的也都全部介紹完給你們了顶别，以上的部分就是我想說的內容，如果你也想在IT行業(yè)拿高薪，可以參加我們的訓練營課程拗胜，選擇最適合自己的課程學習，技術大牛親授怒允，7個月后埂软，進入名企拿高薪。我們的課程內容有：Java工程化纫事、高性能及分布式勘畔、高性能、深入淺出丽惶。高架構炫七。性能調優(yōu)、Spring钾唬，MyBatis万哪，Netty源碼分析和大數(shù)據(jù)等多個知識點侠驯。如果你想拿高薪的，想學習的奕巍，想就業(yè)前景好的吟策，想跟別人競爭能取得優(yōu)勢的，想進阿里面試但擔心面試不過的的止，你都可以來檩坚，群號為：658362658

注：加群要求

1、具有1-5工作經驗的冲杀，面對目前流行的技術不知從何下手效床，需要突破技術瓶頸的可以加。

2权谁、在公司待久了剩檀，過得很安逸，但跳槽時面試碰壁旺芽。需要在短時間內進修沪猴、跳槽拿高薪的可以加。

3采章、如果沒有工作經驗运嗜，但基礎非常扎實，對java工作機制悯舟，常用設計思想担租，常用java開發(fā)框架掌握熟練的，可以加抵怎。

4奋救、覺得自己很牛B，一般需求都能搞定反惕。但是所學的知識點沒有系統(tǒng)化尝艘，很難在技術領域繼續(xù)突破的可以加。

5.阿里Java高級大牛直播講解知識點姿染，分享知識背亥，多年工作經驗的梳理和總結，帶著大家全面悬赏、科學地建立自己的技術體系和技術認知狡汉！

作者：四火，Amazon程序員 全棧工程師 @西雅圖

鏈接：http://www.raychase.net/161?