【正文】 nlike the Service to Worker pattern, the Dispatcher View pattern suggests deferring content retrieval to the time of view processing.In the Dispatcher View pattern, the dispatcher typically plays a limited to moderate role in view management. In the Service to Worker pattern, the dispatcher typically plays a moderate to large role in view management.A limited role for the dispatcher occurs when no outside resources are utilized in order to choose the view. The information encapsulated in the request is sufficient to determine the view to dispatch the request. For example:The sole responsibility of the dispatcher ponent in this case is to dispatch to the view .An example of the dispatcher playing a moderate role is the case where the client submits a request directly to a controller with a query parameter that describes an action to be pleted:The responsibility of the dispatcher ponent here is to translate the logical name login into the resource name of an appropriate view, such as , and dispatch to that view. To acplish this translation, the dispatcher may access resources such as an XML configuration file that specifies the appropriate view to display.On the other hand, in the Service to Worker pattern, the dispatcher might be more sophisticated. The dispatcher may invoke a business service to determine the appropriate view to display.The shared structure of these two patterns, as mentioned above, consists of a controller working with a dispatcher, views, and helpers.. 業(yè)務層模式. Business Delegate—業(yè)務委托模式ContextA multitiered, distributed system requires remote method invocations to send and receive data across tiers. Clients are exposed to the plexity of dealing with distributed ponents.ProblemPresentationtier ponents interact directly with business services. This direct interaction exposes the underlying implementation details of the business service application program interface (API) to the presentation tier. As a result, the presentationtier ponents are vulnerable to changes in the implementation of the business services: When the implementation of the business services change, the exposed implementation code in the presentation tier must change too.Additionally, there may be a detrimental impact on network performance because presentationtier ponents that use the business service API make too many invocations over the network. This happens when presentationtier ponents use the underlying API directly, with no clientside caching mechanism or aggregating service.Lastly, exposing the service APIs directly to the client forces the client to deal with the networking issues associated with the distributed nature of Enterprise JavaBeans (EJB) technology.ForcesPresentationtier clients need access to business services. Different clients, such as devices, Web clients, and thick clients, need access to business service. Business services APIs may change as business requirements evolve. It is desirable to minimize coupling between presentationtier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access. Clients may need to implement caching mechanisms for business service information. It is desirable to reduce network traffic between client and business services. SolutionUse a Business Delegate to reduce coupling between presentationtier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.The Business Delegate acts as a clientside business abstraction。訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類。訪問者模式適用于數據結構相對未定的系統(tǒng)，它把數據結構和作用于結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。不同的子類可以以不同的方式實現(xiàn)這些抽象方法，從而對剩余的邏輯有不同的實現(xiàn)。策略模式把行為和環(huán)境分開。當系統(tǒng)的狀態(tài)變化時，系統(tǒng)便改變所選的子類。這個對象看上去象是改變了它的類一樣。. Observer—觀察者模式想知道咱們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責搜集情報，他發(fā)現(xiàn)的新情報不用一個一個通知我們，直接發(fā)布給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦觀察者模式定義了一種一隊多的依賴關系，讓多個觀察者對象同時監(jiān)聽某一個主題對象。調停者模式將對象的行為和協(xié)作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。從而使他們可以松散偶合。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態(tài)可以是彼此獨立的。Mary：“想要我跟你結婚，得答應我的條件”我：“什么條件我都答應，你說吧”Mary：“我看上了那個一克拉的鉆石”我：“我買，我買，還有嗎？”Mary：“我看上了湖邊的那棟別墅”我：“我買，我買，還有嗎？”Mary：“我看上那輛法拉利跑車”我腦袋嗡的一聲，坐在椅子上，一咬牙：“我買，我買，還有嗎？”迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規(guī)則。給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器。命令模式把發(fā)出命令的責任和執(zhí)行命令的責任分割開，委派給不同的對象。一個請求可以最終不被任何接收端對象所接受。. 行為型模式. Chain Of Responsibility—責任鏈模式晚上去上英語課，為了好開溜坐到了最后一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上“Hi,可以做我的女朋友嗎？如果不愿意請向前傳”，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽說是個老處女呀，快跑!在責任鏈模式中，很多對象由每一個對象對其下家的引用而接起來形成一條鏈。代理就是一個人或一個機構代表另一個人或者一個機構采取行動?？蛻舳瞬豢梢灾苯觿?chuàng)建被共享的對象，而應當使用一個工廠對象負責創(chuàng)建被共享的對象。內蘊狀態(tài)存儲在享元內部，不會隨環(huán)境的改變而有所不同。共享的句子就是Flyweight，MM的名字就是提取出來的外部特征，根據上下文情況使用。門面模式提供一個高層次的接口，使得子系統(tǒng)更易于使用。增加由一些基本功能的排列組合而產生的非常大量的功能。合成模式把部分與整體的關系用樹結構表示出來。”“喂，買了三件了呀，我只答應送一件禮物的哦。. Composite—合成模式Mary今天過生日。單例模式只應在有真正的“單一實例”的需求時才可使用. 結構型模式. Adapter—適配器（變壓器）模式在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助于我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。（100塊錢一份，你要不要）通過給出一個原型對象來指明所要創(chuàng)建的對象的類型，然后用復制這個原型對象的方法創(chuàng)建出更多同類型的對象。建造模式可以強制實行一種分步驟進行的建造過程。如：如何創(chuàng)建及如何向客戶端提供。麥當勞和肯德基就是生產雞翅的Factory客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。. Builder—建造模式MM最愛聽的就是“我愛你”這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出“我愛你”這句話了，國外的MM也可以輕松搞掂，這就是我的“我愛你”builder。. Factory Method—工廠方法模式請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般采用Factory Method模式，帶著MM到服務員那兒，說“要一個漢堡”，具體要什么樣的漢堡呢，讓MM直接跟服務員說就行了。原始模型模式允許動態(tài)的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用于任何的等級結構。適配類可以根據參數返還一個合適的實例給客戶端?！拔疫^生日，你要送我一件禮物?！薄笆裁囱剑琓恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。. Facade—門面模式我有一個專業(yè)的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業(yè)，但MM可不懂這些，教了半天也不會。每一個子系統(tǒng)只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。FLYWEIGHT在拳擊比賽中指最輕量級。外蘊狀態(tài)是隨環(huán)境的改變而改變的。享元模式大幅度的降低內存中對象的數量。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用。請求在這個鏈上傳遞，直到鏈上的某一個對象