23种java设计模式和15种j2ee设计模式

1. JAVA 设计模式 1.1. 创建型模式 1.1.1. Abstract Factory—抽象工厂模式 追 MM 少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西， 虽然口味有所不同，但不管你带 MM 去麦当劳或肯德基，只管向服务员说“来四个鸡 翅”就行了。麦当劳和肯德基就是生产鸡翅的 Factory 客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。 消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。 如：如何创建及如何向客户端提供。 1.1.2. Builder—建造模式 MM 最爱听的就是“我爱你”这句话了，见到不同地方的 MM,要能够用她们的 方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到 MM 我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的 MM 也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻 译机好卖） 将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有 不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必 知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 1.1.3. Factory Method—工厂方法模式 请 MM 去麦当劳吃汉堡，不同的 MM 有不同的口味，要每个都记住是一件烦人 的事情，我一般采用 Factory Method 模式，带着 MM 到服务员那儿，说“要一个汉堡”， 具体要什么样的汉堡呢，让 MM 直接跟服务员说就行了。 核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做， 成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产 品类应当被实例化这种细节。 1.1.4. Prototype—原始模型模式 跟 MM 用 QQ 聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需 要时只要 copy 出来放到 QQ 里面就行了，这就是我的情话 prototype 了。（100 块钱一 份，你要不要） 通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对 象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产 品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。 缺点是每一个类都必须配备一个克隆方法。 1.1.5. Singleton—单例模式 俺有 6 个漂亮的老婆，她们的老公都是我，我就是我们家里的老公 Sigleton，她 们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的 事) 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个 实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用 1.2. 结构型模式 1.2.1. Adapter—适配器（变压器）模式 在朋友聚会上碰到了一个美女 Sarah，从香港来的，可我不会说粤语，她不会说 普通话，只好求助于我的朋友 kent 了，他作为我和 Sarah 之间的 Adapter，让我和 Sarah 可以相互交谈了(也不知道他会不会耍我) 把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不 匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实 例给客户端。 1.2.2. Bridge—桥梁模式 早上碰到 MM，要说早上好，晚上碰到 MM，要说晚上好；碰到 MM 穿了件新 衣服，要说你的衣服好漂亮哦，碰到 MM 新做的发型，要说你的头发好漂亮哦。不要 问我“早上碰到 MM 新做了个发型怎么说”这种问题，自己用 BRIDGE 组合一下不 就行了 将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强 关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系 而不是继承关系，从而使两者可以独立的变化。 1.2.3. Composite—合成模式 Mary 今天过生日。 “我过生日，你要送我一件礼物。” “嗯，好吧，去商店，你自己挑。” “这件 T 恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。” “喂，买了三件了呀，我只答应送一件礼物的哦。” “什么呀，T 恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。” “„„”， MM 都会用 Composite 模式了，你会了没有？ 合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式 就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出 来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等 看待。 1.2.4. Decorator—装饰模式 Mary 过完轮到 Sarly 过生日，还是不要叫她自己挑了，不然这个月伙食费肯定 玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的 Fita”， 再到街上礼品店买了个像框（卖礼品的 MM 也很漂亮哦），再找隔壁搞美术设计的 Mike 设计了一个漂亮的盒子装起来„„，我们都是 Decorator，最终都在修饰我这个人呀， 怎么样，看懂了吗？ 装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案， 提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。 增加由一些基本功能的排列组合而产生的非常大量的功能。 1.2.5. Facade—门面模式 我有一个专业的 Nikon 相机，我就喜欢自己手动调光圈、快门，这样照出来的 照片才专业，但 MM 可不懂这些，教了半天也不会。幸好相机有 Facade 设计模式， 把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样 MM 也可以用这个相机给我拍张照片了。 外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一 个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门 面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 1.2.6. Flyweight—享元模式 每天跟 MM 发短信，手指都累死了，最近买了个新手机，可以把一些常用的句 子存在手机里，要用的时候，直接拿出来，在前面加上 MM 的名字就可以发送了，再 不用一个字一个字敲了。共享的句子就是 Flyweight，MM 的名字就是提取出来的外部 特征，根据上下文情况使用。 FLYWEIGHT 在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大 量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态 存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。 外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的 状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接 创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅 度的降低内存中对象的数量。 1.2.7. Proxy—代理模式 跟 MM 在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？” “身高多少呀？”这些话，真烦人，写个程序做为我的 Proxy 吧，凡是接收到这些话 都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。 代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。 代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户 不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的 作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的 被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理 对象，被代理对象必须有系统的其他角色代为创建并传入。 1.3. 行为型模式 1.3.1. Chain Of Responsibility—责任链模式 晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的 MM 哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个 接一个的传上去了，糟糕，传到第一排的 MM 把纸条传给老师了，听说是个老处女呀， 快跑! 在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。 请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的 哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链 和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终 不被任何接收端对象所接受。 1.3.2. Command—命令模式 俺有一个 MM 家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传 送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过 来一个 COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我 姐姐三个男朋友送 COMMAND，就数你最小气，才请我吃面。”， 命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任 和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一 方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎 么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤 消。 1.3.3. Interpreter—解释器模式 俺有一个《泡 MM 真经》，上面有各种泡 MM 的攻略，比如说去吃西餐的步骤、 去看电影的方法等等，跟 MM 约会时，只要做一个 Interpreter，照着上面的脚本执行 就可以了。 给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个 解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎 样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的 语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文 法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方 法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个 语言。 1.3.4. Iterator—迭代子模式 我爱上了 Mary，不顾一切的向她求婚。 Mary：“想要我跟你结婚，得答应我的条件” 我：“什么条件我都答应，你说吧” Mary：“我看上了那个一克拉的钻石” 我：“我买，我买，还有吗？” Mary：“我看上了湖边的那栋别墅” 我：“我买，我买，还有吗？” Mary：“我看上那辆法拉利跑车” 我脑袋嗡的一声，坐在椅子上，一咬牙：“我买，我买，还有吗？” 迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个 对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭 代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式 简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个 迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。 1.3.5. Mediator—调停者模式 四个 MM 打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边， 按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就 OK 啦， 俺得到了四个 MM 的电话。 调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作 用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其 他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多 的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对 象在小尺度的行为上与其他对象的相互作用分开处理。 1.3.6. Memento—备忘录模式 同时跟几个 MM 聊天时，一定要记清楚刚才跟 MM 说了些什么话，不然 MM 发 现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个 MM 说了什么话我都拷贝一份放 到备忘录里面保存，这样可以随时察看以前的记录啦。 备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式 的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从 而可以在将来合适的时候把这个对象还原到存储起来的状态。 1.3.7. Observer—观察者模式 想知道咱们公司最新 MM 情报吗？加入公司的 MM 情报邮件组就行了，tom 负 责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为 订阅者（观察者）就可以及时收到情报啦 观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个 主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够 自动更新自己。 1.3.8. State—状态模式 跟 MM 交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同， 比如你约她今天晚上去看电影，对你没兴趣的 MM 就会说“有事情啦”，对你不讨厌 但还没喜欢上的 MM 就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的 MM 就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话， 也可以把 MM 的状态从不讨厌不喜欢变成喜欢哦。 状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象 是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每 一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其 内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状 态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。 1.3.9. Strategy—策略模式 跟不同类型的 MM 约会，要用不同的策略，有的请电影比较好，有的则去吃小 吃效果不错，有的去海边浪漫最合适，单目的都是为了得到 MM 的芳心，我的追 MM 锦囊中有好多 Strategy 哦。 策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从 而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变 化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的 策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客 户端。 1.3.10. Template Method—模板方法模式 看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤 分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具 体实现)； 模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式 实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的 方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架， 而将逻辑的细节留给具体的子类去实现。 1.3.11. Visitor—访问者模式 情人节到了，要给每个 MM 送一束鲜花和一张卡片，可是每个 MM 送的花都要 针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是 找花店老板和礼品店老板做一下 Visitor，让花店老板根据 MM 的特点选一束花，让礼 品店老板也根据每个人特点选一张卡，这样就轻松多了； 访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些 操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据 结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得 操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加 一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散 到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问 者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不 同的等级结构的成员类。 2. J2EE 设计模式 2.1. 表示层模式 2.1.1. Intercepting Filter—拦截过滤器模式 Context The presentation-tier request handling mechanism receives many different types of requests, which require varied types of processing. Some requests are simply forwarded to the appropriate handler component, while other requests must be modified, audited, or uncompressed before being further processed. Problem Preprocessing and post-processing of a client Web request and response are required. When a request enters a Web application, it often must pass several entrance tests prior to the main processing stage. For example, Has the client been authenticated? Does the client have a valid session? Is the client's IP address from a trusted network? Does the request path violate any constraints? What encoding does the client use to send the data? Do we support the browser type of the client? Some of these checks are tests, resulting in a yes or no answer that determines whether processing will continue. Other checks manipulate the incoming data stream into a form suitable for processing. The classic solution consists of a series of conditional checks, with any failed check aborting the request. Nested if/else statements are a standard strategy, but this solution leads to code fragility and a copy-and-paste style of programming, because the flow of the filtering and the action of the filters is compiled into the application. The key to solving this problem in a flexible and unobtrusive manner is to have a simple mechanism for adding and removing processing components, in which each component completes a specific filtering action. Forces Common processing, such as checking the data-encoding scheme or logging information about each request, completes per request. Centralization of common logic is desired. Services should be easy to add or remove unobtrusively without affecting existing components, so that they can be used in a variety of combinations, such as Logging and authentication Debugging and transformation of output for a specific client Uncompressing and converting encoding scheme of input Solution Create pluggable filters to process common services in a standard manner without requiring changes to core request processing code. The filters intercept incoming requests and outgoing responses, allowing preprocessing and post-processing. We are able to add and remove these filters unobtrusively, without requiring changes to our existing code. We are able, in effect, to decorate our main processing with a variety of common services, such as security, logging, debugging, and so forth. These filters are components that are independent of the main application code, and they may be added or removed declaratively. For example, a deployment configuration file may be modified to set up a chain of filters. The same configuration file might include a mapping of specific URLs to this filter chain. When a client requests a resource that matches this configured URL mapping, the filters in the chain are each processed in order before the requested target resource is invoked. 2.1.2. Front Controller—前端控制器模式 Context The presentation-tier request handling mechanism must control and coordinate processing of each user across multiple requests. Such control mechanisms may be managed in either a centralized or decentralized manner. Problem The system requires a centralized access point for presentation-tier request handling to support the integration of system services, content retrieval, view management, and navigation. When the user accesses the view directly without going through a centralized mechanism, two problems may occur: Each view is required to provide its own system services, often resulting in duplicate code. View navigation is left to the views. This may result in commingled view content and view navigation. Additionally, distributed control is more difficult to maintain, since changes will often need to be made in numerous places. Forces Common system services processing completes per request. For example, the security service completes authentication and authorization checks. Logic that is best handled in one central location is instead replicated within numerous views. Decision points exist with respect to the retrieval and manipulation of data. Multiple views are used to respond to similar business requests. A centralized point of contact for handling a request may be useful, for example, to control and log a user's progress through the site. System services and view management logic are relatively sophisticated. Solution Use a controller as the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies. The controller provides a centralized entry point that controls and manages Web request handling. By centralizing decision points and controls, the controller also helps reduce the amount of Java code, called scriptlets, embedded in the JavaServer Pages (JSP) page. Centralizing control in the controller and reducing business logic in the view promotes code reuse across requests. It is a preferable approach to the alternative-embedding code in multiple views-because that approach may lead to a more error-prone, reuse-by-copy- and-paste environment. Typically, a controller coordinates with a dispatcher component. Dispatchers are responsible for view management and navigation. Thus, a dispatcher chooses the next view for the user and vectors control to the resource. Dispatchers may be encapsulated within the controller directly or can be extracted into a separate component. While the Front Controller pattern suggests centralizing the handling of all requests, it does not limit the number of handlers in the system, as does a Singleton. An application may use multiple controllers in a system, each mapping to a set of distinct services. 2.1.3. View Helper—视图助手模式 Context The system creates presentation content, which requires processing of dynamic business data. Problem Presentation tier changes occur often and are difficult to develop and maintain when business data access logic and presentation formatting logic are interwoven. This makes the system less flexible, less reusable, and generally less resilient to change. Intermingling the business and systems logic with the view processing reduces modularity and also provides a poor separation of roles among Web production and software development teams. Forces Business data assimilation requirements are nontrivial. Embedding business logic in the view promotes a copy-and-paste type of reuse. This causes maintenance problems and bugs because a piece of logic is reused in the same or different view by simply duplicating it in the new location. It is desirable to promote a clean separation of labor by having different individuals fulfill the roles of software developer and Web production team member. One view is commonly used to respond to a particular business request. Solution A view contains formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's intermediate data model and serve as business data adapters. There are multiple strategies for implementing the view component. The JSP View Strategy suggests using a JSP as the view component. This is the preferred strategy, and it is the one most commonly used. The other principal strategy is the Servlet View Strategy, which utilizes a servlet as the view (see the section "Strategies" for more information). Encapsulating business logic in a helper instead of a view makes our application more modular and facilitates component reuse. Multiple clients, such as controllers and views, may leverage the same helper to retrieve and adapt similar model state for presentation in multiple ways. The only way to reuse logic embedded in a view is by copying and pasting it elsewhere. Furthermore, copy-and-paste duplication makes a system harder to maintain, since the same bug potentially needs to be corrected in multiple places. A signal that one may need to apply this pattern to existing code is when scriptlet code dominates the JSP view. The overriding goal when applying this pattern, then, is the partitioning of business logic outside of the view. While some logic is best encapsulated within helper objects, other logic is better placed in a centralized component that sits in front of the views and the helpers-this might include logic that is common across multiple requests, such as authentication checks or logging services, for example. Refer to the "Intercepting Filter" on page 4 and "Front Controller" on page 21 for more information on these issues. If a separate controller is not employed in the architecture, or is not used to handle all requests, then the view component becomes the initial contact point for handling some requests. For certain requests, particularly those involving minimal processing, this scenario works fine. Typically, this situation occurs for pages that are based on static information, such as the first of a set of pages that will be served to a user to gather some information (see "Dispatcher View" on page 232). Additionally, this scenario occurs in some cases when a mechanism is employed to create composite pages (see "Composite View" on page 203). The View Helper pattern focuses on recommending ways to partition your application responsibilities. For related discussions about issues dealing with directing client requests directly to a view, please refer to the section "Dispatcher View" on page 232. 2.1.4. Composite View—复合视图模式 Context Sophisticated Web pages present content from numerous data sources, using multiple subviews that comprise a single display page. Additionally, a variety of individuals with different skill sets contribute to the development and maintenance of these Web pages. Problem Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding formatting code directly within each view. Modification to the layout of multiple views is difficult and error prone, due to the duplication of code. Forces Atomic portions of view content change frequently. Multiple composite views use similar subviews, such as a customer inventory table. These atomic portions are decorated with different surrounding template text, or they appear in a different location within the page. Layout changes are more difficult to manage and code harder to maintain when subviews are directly embedded and duplicated in multiple views. Embedding frequently changing portions of template text directly into views also potentially affects the availability and administration of the system. The server may need to be restarted before clients see the modifications or updates to these template components. Solution Use composite views that are composed of multiple atomic subviews. Each component of the template may be included dynamically into the whole and the layout of the page may be managed independently of the content. This solution provides for the creation of a composite view based on the inclusion and substitution of modular dynamic and static template fragments. It promotes the reuse of atomic portions of the view by encouraging modular design. It is appropriate to use a composite view to generate pages containing display components that may be combined in a variety of ways. This scenario occurs, for example, with portal sites that include numerous independent subviews, such as news feeds, weather information, and stock quotes on a single page. The layout of the page is managed and modified independent of the subview content. Another benefit of this pattern is that Web designers can prototype the layout of a site, plugging static content into each of the template regions. As site development progresses, the actual content is substituted for these placeholders. This pattern is not without its drawbacks. There is a runtime overhead associated with it, a tradeoff for the increased flexibility that it provides. Also, the use of a more sophisticated layout mechanism brings with it some manageability and development issues, since there are more artifacts to maintain and a level of implementation indirection to understand. 2.1.5. Service to Worker—工作者服务模式 Context The system controls flow of execution and access to business data, from which it creates presentation content. Note The Service to Worker pattern, like the Dispatcher View pattern, describes a common combination of other patterns from the catalog. Both of these macro patterns describe the combination of a controller and dispatcher with views and helpers. While describing this common structure, they emphasize related but different usage patterns. Problem The problem is a combination of the problems solved by the Front Controller and View Helper patterns in the presentation tier. There is no centralized component for managing access control, content retrieval, or view management, and there is duplicate control code scattered throughout various views. Additionally, business logic and presentation formatting logic are intermingled within these views, making the system less flexible, less reusable, and generally less resilient to change. Intermingling business logic with view processing also reduces modularity and provides a poor separation of roles among Web production and software development teams. Forces Authentication and authorization checks are completed per request. Scriptlet code within views should be minimized. Business logic should be encapsulated in components other than the view. Control flow is relatively complex and based on values from dynamic content. View management logic is relatively sophisticated, with multiple views potentially mapping to the same request. Solution Combine a controller and dispatcher with views and helpers (see "Front Controller" on page 172 and "View Helper" on page 186) to handle client requests and prepare a dynamic presentation as the response. Controllers delegate content retrieval to helpers, which manage the population of the intermediate model for the view. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller or a separate component. Service to Worker describes the combination of the Front Controller and View Helper patterns with a dispatcher component. While this pattern and the Dispatcher View pattern describe a similar structure, the two patterns suggest a different division of labor among the components. In Service to Worker, the controller and the dispatcher have more responsibilities. Since the Service to Worker and Dispatcher View patterns represent a common combination of other patterns from the catalog, each warrants its own name to promote efficient communication among developers. Unlike 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, http://some.server.com/servlet/Controller?next=login.jsp The sole responsibility of the dispatcher component in this case is to dispatch to the view login.jsp. 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 completed: http://some.server.com/servlet/Controller?action=login The responsibility of the dispatcher component here is to translate the logical name login into the resource name of an appropriate view, such as login.jsp, and dispatch to that view. To accomplish 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 Service to Worker and Dispatcher View consists of a controller working with a dispatcher, views, and helpers. 2.1.6. Dispatcher View—分发者视图模式 Context System controls flow of execution and access to presentation processing, which is responsible for generating dynamic content. Note The Dispatcher View pattern, like the Service to Worker pattern, describes a common combination of other patterns from the catalog. Both of these macro patterns describe the combination of a controller and dispatcher with views and helpers. While describing this common structure, they emphasize related but different usage patterns. Problem The problem is a combination of the problems solved by the Front Controller and View Helper patterns in the presentation tier. There is no centralized component for managing access control, content retrieval or view management, and there is duplicate control code scattered throughout various views. Additionally, business logic and presentation formatting logic are intermingled within these views, making the system less flexible, less reusable, and generally less resilient to change. Intermingling business logic with view processing also reduces modularity and provides a poor separation of roles among Web production and software development teams. Forces Authentication and authorization checks are completed per request. Scriptlet code within views should be minimized. Business logic should be encapsulated in components other than the view. Control flow is relatively simple and is typically based on values encapsulated with the request. View management logic is limited in complexity. Solution Combine a controller and dispatcher with views and helpers (see "Front Controller" on page 172 and "View Helper" on page 186) to handle client requests and prepare a dynamic presentation as the response. Controllers do not delegate content retrieval to helpers, because these activities are deferred to the time of view processing. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller, a view, or a separate component. Dispatcher View describes the combination of the Front Controller and View Helper patterns with a dispatcher component. While this pattern and the Service to Worker pattern describe a similar structure, the two patterns suggest a different division of labor among the components. The controller and the dispatcher typically have limited responsibilities, as compared to the Service to Worker pattern, since the upfront processing and view management logic are basic. Furthermore, if centralized control of the underlying resources is considered unnecessary, then the controller is removed and the dispatcher may be moved into a view. Since the Service to Worker and Dispatcher View patterns represent a common combination of other patterns from the catalog, each warrants its own name to promote efficient communication among developers. Unlike 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: http://some.server.com/servlet/Controller?next=login.jsp The sole responsibility of the dispatcher component in this case is to dispatch to the view login.jsp. 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 completed: http://some.server.com/servlet/Controller?action=login The responsibility of the dispatcher component here is to translate the logical name login into the resource name of an appropriate view, such as login.jsp, and dispatch to that view. To accomplish 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. 2.2. 业务层模式 2.2.1. Business Delegate—业务委托模式 Context A multi-tiered, distributed system requires remote method invocations to send and receive data across tiers. Clients are exposed to the complexity of dealing with distributed components. Problem Presentation-tier components 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 presentation-tier components 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 presentation-tier components that use the business service API make too many invocations over the network. This happens when presentation-tier components use the underlying API directly, with no client-side 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. Forces Presentation-tier 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 presentation-tier 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. Solution Use a Business Delegate to reduce coupling between presentation-tier 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 client-side business abstraction; it provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services. Depending on the implementation strategy, the Business Delegate may shield clients from possible volatility in the implementation of the business service API. Potentially, this reduces the number of changes that must be made to the presentation-tier client code when the business service API or its underlying implementation changes. However, interface methods in the Business Delegate may still require modification if the underlying business service API changes. Admittedly, though, it is more likely that changes will be made to the business service rather than to the Business Delegate. Often, developers are skeptical when a design goal such as abstracting the business layer causes additional upfront work in return for future gains. However, using this pattern or its strategies results in only a small amount of additional upfront work and provides considerable benefits. The main benefit is hiding the details of the underlying service. For example, the client can become transparent to naming and lookup services. The Business Delegate also handles the exceptions from the business services, such as java.rmi.Remote exceptions, Java Messages Service (JMS) exceptions and so on. The Business Delegate may intercept such service level exceptions and generate application level exceptions instead. Application level exceptions are easier to handle by the clients, and may be user friendly. The Business Delegate may also transparently perform any retry or recovery operations necessary in the event of a service failure without exposing the client to the problem until it is determined that the problem is not resolvable. These gains present a compelling reason to use the pattern. Another benefit is that the delegate may cache results and references to remote business services. Caching can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network. A Business Delegate uses a component called the Lookup Service. The Lookup Service is responsible for hiding the underlying implementation details of the business service lookup code. The Lookup Service may be written as part of the Delegate, but we recommend that it be implemented as a separate component, as outlined in the Service Locator pattern (See "Service Locator" on page 368.) When the Business Delegate is used with a Session Facade, typically there is a one-to-one relationship between the two. This one-to-one relationship exists because logic that might have been encapsulated in a Business Delegate relating to its interaction with multiple business services (creating a one-to-many relationship) will often be factored back into a Session Facade. Finally, it should be noted that this pattern could be used to reduce coupling between other tiers, not simply the presentation and the business tiers. 2.2.2. Transfer Object—传输对象模式 Context Application clients need to exchange data with enterprise beans. Problem Java 2 Platform, Enterprise Edition (J2EE) applications implement server-side business components as session beans and entity beans. Some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values. Session beans represent the business services and are not shared between users. A session bean provides coarse-grained service methods when implemented per the Session Facade pattern. Entity beans, on the other hand, are multiuser, transactional objects representing persistent data. An entity bean exposes the values of attributes by providing an accessor method (also referred to as a getter or get method) for each attribute it wishes to expose. Every method call made to the business service object, be it an entity bean or a session bean, is potentially remote. Thus, in an Enterprise JavaBeans (EJB) application such remote invocations use the network layer regardless of the proximity of the client to the bean, creating a network overhead. Enterprise bean method calls may permeate the network layers of the system even if the client and the EJB container holding the entity bean are both running in the same JVM, OS, or physical machine. Some vendors may implement mechanisms to reduce this overhead by using a more direct access approach and bypassing the network. As the usage of these remote methods increases, application performance can significantly degrade. Therefore, using multiple calls to get methods that return single attribute values is inefficient for obtaining data values from an enterprise bean. Forces All access to an enterprise bean is performed via remote interfaces to the bean. Every call to an enterprise bean is potentially a remote method call with network overhead. Typically, applications have a greater frequency of read transactions than update transactions. The client requires the data from the business tier for presentation, display, and other read-only types of processing. The client updates the data in the business tier much less frequently than it reads the data. The client usually requires values for more than one attribute or dependent object from an enterprise bean. Thus, the client may invoke multiple remote calls to obtain the required data. The number of calls made by the client to the enterprise bean impacts network performance. Chattier applications-those with increased traffic between client and server tiers-often degrade network performance. Solution Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client. Clients usually require more than one value from an enterprise bean. To reduce the number of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to transport the data from the enterprise bean to its client. When an enterprise bean uses a Transfer Object, the client makes a single remote method invocation to the enterprise bean to request the Transfer Object instead of numerous remote method calls to get individual attribute values. The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client. The client receives the Transfer Object and can then invoke accessor (or getter) methods on the Transfer Object to get the individual attribute values from the Transfer Object. Or, the implementation of the Transfer Object may be such that it makes all attributes public. Because the Transfer Object is passed by value to the client, all calls to the Transfer Object instance are local calls instead of remote method invocations. 2.2.3. Session Facade—会话门面模式 Context Enterprise beans encapsulate business logic and business data and expose their interfaces, and thus the complexity of the distributed services, to the client tier. Problem In a multitiered Java 2 Platform, Enterprise Edition (J2EE) application environment, the following problems arise: Tight coupling, which leads to direct dependence between clients and business objects; Too many method invocations between client and server, leading to network performance problems; Lack of a uniform client access strategy, exposing business objects to misuse. A multitiered J2EE application has numerous server-side objects that are implemented as enterprise beans. In addition, some other arbitrary objects may provide services, data, or both. These objects are collectively referred to as business objects, since they encapsulate business data and business logic. J2EE applications implement business objects that provide processing services as session beans. Coarse-grained business objects that represent an object view of persistent storage and are shared by multiple users are usually implemented as entity beans. Application clients need access to business objects to fulfill their responsibilities and to meet user requirements. Clients can directly interact with these business objects because they expose their interfaces. When you expose business objects to the client, the client must understand and be responsible for the business data object relationships, and must be able to handle business process flow. However, direct interaction between the client and the business objects leads to tight coupling between the two, and such tight coupling makes the client directly dependent on the implementation of the business objects. Direct dependence means that the client must represent and implement the complex interactions regarding business object lookups and creations, and must manage the relationships between the participating business objects as well as understand the responsibility of transaction demarcation. As client requirements increase, the complexity of interaction between various business objects increases. The client grows larger and more complex to fulfill these requirements. The client becomes very susceptible to changes in the business object layer; in addition, the client is unnecessarily exposed to the underlying complexity of the system. Tight coupling between objects also results when objects manage their relationship within themselves. Often, it is not clear where the relationship is managed. This leads to complex relationships between business objects and rigidity in the application. Such lack of flexibility makes the application less manageable when changes are required. When accessing the enterprise beans, clients interact with remote objects. Network performance problems may result if the client directly interacts with all the participating business objects. When invoking enterprise beans, every client invocation is potentially a remote method call. Each access to the business object is relatively fine-grained. As the number of participants increases in a scenario, the number of such remote method calls increases. As the number of remote method calls increases, the chattiness between the client and the server-side business objects increases. This may result in network performance degradation for the application, because the high volume of remote method calls increases the amount of interaction across the network layer. A problem also arises when a client interacts directly with the business objects. Since the business objects are directly exposed to the clients, there is no unified strategy for accessing the business objects. Without such a uniform client access strategy, the business objects are exposed to clients and may reduce consistent usage. Forces Provide a simpler interface to the clients by hiding all the complex interactions between business components. Reduce the number of business objects that are exposed to the client across the service layer over the network. Hide from the client the underlying interactions and interdependencies between business components. This provides better manageability, centralization of interactions (responsibility), greater flexibility, and greater ability to cope with changes. Provide a uniform coarse-grained service layer to separate business object implementation from business service abstraction. Avoid exposing the underlying business objects directly to the client to keep tight coupling between the two tiers to a minimum. Solution Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients. The Session Facade abstracts the underlying business object interactions and provides a service layer that exposes only the required interfaces. Thus, it hides from the client's view the complex interactions between the participants. The Session Facade manages the interactions between the business data and business service objects that participate in the workflow, and it encapsulates the business logic associated with the requirements. Thus, the session bean (representing the Session Facade) manages the relationships between business objects. The session bean also manages the life cycle of these participants by creating, locating (looking up), modifying, and deleting them as required by the workflow. In a complex application, the Session Facade may delegate this lifestyle management to a separate object. For example, to manage the lifestyle of participant session and entity beans, the Session Facade may delegate that work to a Service Locator object (see "Service Locator" on page 368). It is important to examine the relationship between business objects. Some relationships between business objects are transient, which means that the relationship is applicable to only that interaction or scenario. Other relationships may be more permanent. Transient relationships are best modeled as workflow in a facade, where the facade manages the relationships between the business objects. Permanent relationships between two business objects should be studied to determine which business object (if not both objects) maintains the relationship. Use Cases and Session Facades So, how do you identify the Session Facades through studying use cases? Mapping every use case to a Session Facade will result in too many Session Facades. This defeats the intention of having fewer coarse-grained session beans. Instead, as you derive the Session Facades during your modeling, look to consolidate them into fewer numbers of session beans based on some logical partitioning. For example, for a banking application, you may group the interactions related to managing an account into a single facade. The use cases Create New Account, Change Account Information, View Account information, and so on all deal with the coarse-grained entity object Account. Creating a session bean facade for each use case is not recommended. Thus, the functions required to support these related use cases could be grouped into a single Session Facade called AccountSessionFacade. In this case, the Session Facade will become a highly coarse-grained controller with high-level methods that can facilitate each interaction (that is, createNewAccount, changeAccount, getAccount). Therefore, we recommend that you design Session Facades to aggregate a group of the related interactions into a single Session Facade. This results in fewer Session Facades for the application, and leverages the benefits of the Session Facade pattern. 2.2.4. Composite Entity—复合实体模式 Context Entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects. Problem In a Java 2 Platform, Enterprise Edition (J2EE) application, clients -- such as applications, JavaServer Pages (JSP) pages, servlets, JavaBeans components -- access entity beans via their remote interfaces. Thus, every client invocation potentially routes through network stubs and skeletons, even if the client and the enterprise bean are in the same JVM, OS, or machine. When entity beans are fine-grained objects, clients tend to invoke more individual entity bean methods, resulting in high network overhead. Entity beans represent distributed persistent business objects. Whether developing or migrating an application to the J2EE platform, object granularity is very important when deciding what to implement as an entity bean. Entity beans should represent coarse-grained business objects, such as those that provide complex behavior beyond simply getting and setting field values. These coarse-grained objects typically have dependent objects. A dependent object is an object that has no real domain meaning when not associated with its coarse-grained parent. A recurring problem is the direct mapping of the object model to an Enterprise JavaBeans (EJB) model (specifically entity beans). This creates a relationship between the entity bean objects without consideration of coarse-grained versus fine-grained (or dependent) objects. Determining what to make coarse-grained versus fine-grained is typically difficult and can best be done via modeling relationships in Unified Modeling Language (UML) models. There are a number of areas impacted by the fine-grained entity bean design approach: Entity Relationships - Directly mapping an object model to an EJB model does not take into account the impact of relationships between the objects. The inter-object relationships are directly transformed into inter-entity bean relationships. As a result, an entity bean might contain or hold a remote reference to another entity bean. However, maintaining remote references to distributed objects involves different techniques and semantics than maintaining references to local objects. Besides increasing the complexity of the code, it reduces flexibility, because the entity bean must change if there are any changes in its relationships. Also, there is no guarantee as to the validity of the entity bean references to other entity beans over time. Such references are established dynamically using the entity's home object and the primary key for that entity bean instance. This implies a high maintenance overhead of reference validity checking for each such entity-bean-to-entity-bean reference. Manageability - Implementing fine-grained objects as entity beans results in a large number of entity beans in the system. An entity bean is defined using several classes. For each entity bean component, the developer must provide classes for the home interface, the remote interface, the bean implementation, and the primary key. In addition, the container may generate classes to support the entity bean implementation. When the bean is created, these classes are realized as real objects in the container. In short, the container creates a number of objects to support each entity bean instance. Large numbers of entity beans result in more classes and code to maintain for the development team. It also results in a large number of objects in the container. This can negatively impact the application performance. Network Performance - Fine-grained entity beans potentially have more inter-entity bean relationships. Entity beans are distributed objects. When one entity bean invokes a method on another entity bean, the call is potentially treated as a remote call by the container, even if both entity beans are in the same container or JVM. If the number of entity-bean-to-entity-bean relationships increases, then this decreases system scalability due to heavy network overhead. Database Schema Dependency - When the entity beans are fine-grained, each entity bean instance usually represents a single row in a database. This is not a proper application of the entity bean design, since entity beans are more suitable for coarse-grained components. Fine-grained entity bean implementation typically is a direct representation of the underlying database schema in the entity bean design. When clients use these fine-grained entity beans, they are essentially operating at the row level in the database, since each entity bean is effectively a single row. Because the entity bean directly models a single database row, the clients become dependent on the database schema. When the schema changes, the entity bean definitions must change as well. Further, since the clients are operating at the same granularity, they must observe and react to this change. This schema dependency causes a loss of flexibility and increases the maintenance overhead whenever schema changes are required. Object Granularity (Coarse-Grained versus Fine-Grained) - Object granularity impacts data transfer between the enterprise bean and the client. In most applications, clients typically need a larger chunk of data than one or two rows from a table. In such a case, implementing each of these fine-grained objects as an entity bean means that the client would have to manage the relationships between all these fine-grained objects. Depending on the data requirements, the client might have to perform many lookups of a number of entity beans to obtain the required information. Forces Entity beans are best implemented as coarse-grained objects due to the high overhead associated with each entity bean. Each entity bean is implemented using several objects, such as EJB home object, remote object, bean implementation, and primary key, and each is managed by the container services. Applications that directly map relational database schema to entity beans (where each row in a table is represented by an entity bean instance) tend to have a large number of fine-grained entity beans. It is desirable to keep the entity beans coarse-grained and reduce the number of entity beans in the application. Direct mapping of object model to EJB model yields fine-grained entity beans. Fine-grained entity beans usually map to the database schema. This entity-to-database row mapping causes problems related to performance, manageability, security, and transaction handling. Relationships between tables are implemented as relationships between entity beans, which means that entity beans hold references to other entity beans to implement the fine-grained relationships. It is very expensive to manage inter-entity bean relationships, because these relationships must be established dynamically, using the entity home objects and the enterprise beans' primary keys. Clients do not need to know the implementation of the database schema to use and support the entity beans. With fine-grained entity beans, the mapping is usually done so that each entity bean instance maps to a single row in the database. This fine-grained mapping creates a dependency between the client and the underlying database schema, since the clients deal with the fine-grained beans and they are essentially a direct representation of the underlying schema. This results in tight coupling between the database schema and entity beans. A change to the schema causes a corresponding change to the entity bean, and in addition requires a corresponding change to the clients. There is an increase in chattiness of applications due to intercommunication among fine-grained entity beans. Excessive inter-entity bean communication often leads to a performance bottleneck. Every method call to the entity bean is made via the network layer, even if the caller is in the same address space as the called bean (that is, both the client, or caller entity bean, and the called entity bean are in the same container). While some container vendors optimize for this scenario, the developer cannot rely on this optimization in all containers. Additional chattiness can be observed between the client and the entity beans because the client may have to communicate with many fine-grained entity beans to fulfill a requirement. It is desirable to reduce the communication between or among entity beans and to reduce the chattiness between the client and the entity bean layer. Solution Use Composite Entity to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans. A Composite Entity bean represents a graph of objects. In order to understand this solution, let us first define what is meant by persistent objects and discuss their relationships. A persistent object is an object that is stored in some type of data store. Multiple clients usually share persistent objects. Persistent objects can be classified into two types: coarse-grained objects and dependent objects. A coarse-grained object is self-sufficient. It has its own life cycle and manages its relationships to other objects. Each coarse-grained object may reference or contain one or more other objects. The coarse-grained object usually manages the lifecycles of these objects. Hence, these objects are called dependent objects. A dependent object can be a simple self-contained object or may in turn contain other dependent objects. The life cycle of a dependent object is tightly coupled to the life cycle of the coarse-grained object. A client may only indirectly access a dependent object through the coarse-grained object. That is, dependent objects are not directly exposed to clients because their parent (coarse-grained) object manages them. Dependent objects cannot exist by themselves. Instead, they always need to have their coarse-grained (or parent) object to justify their existence. Typically, you can view the relationship between a coarse-grained object and its dependent objects as a tree. The coarse-grained object is the root of the tree (the root node). Each dependent object can be a standalone dependent object (a leaf node) that is a child of the coarse-grained object. Or, the dependent object can have parent-child relationships with other dependent objects, in which case it is considered a branch node. A Composite Entity bean can represent a coarse-grained object and all its related dependent objects. Aggregation combines interrelated persistent objects into a single entity bean, thus drastically reducing the number of entity beans required by the application. This leads to a highly coarse-grained entity bean that can better leverage the benefits of entity beans than can fine-grained entity beans. Without the Composite Entity approach, there is a tendency to view each coarse-grained and dependent object as a separate entity bean, leading to a large number of entity beans. 2.2.5. Transfer Object Assembler—传输对象组装器模式 Context In a Java 2 Platform, Enterprise Edition (J2EE) application, the server-side business components are implemented using session beans, entity beans, DAOs, and so forth. Application clients frequently need to access data that is composed from multiple objects. Problem Application clients typically require the data for the model or parts of the model to present to the user or to use for an intermediate processing step before providing some service. The application model is an abstraction of the business data and business logic implemented on the server side as business components. A model may be expressed as a collection of objects put together in a structured manner (tree or graph). In a J2EE application, the model is a distributed collection of objects such as session beans, entity beans, or DAOs and other objects. For a client to obtain the data for the model, such as to display to the user or to perform some processing, it must access individually each distributed object that defines the model. This approach has several drawbacks: Because the client must access each distributed component individually, there is a tight coupling between the client and the distributed components of the model over the network The client accesses the distributed components via the network layer, and this can lead to performance degradation if the model is complex with numerous distributed components. Network and client performance degradation occur when a number of distributed business components implement the application model and the client directly interacts with these components to obtain model data from that component. Each such access results in a remote method call that introduces network overhead and increases the chattiness between the client and the business tier. The client must reconstruct the model after obtaining the model's parts from the distributed components. The client therefore needs to have the necessary business logic to construct the model. If the model construction is complex and numerous objects are involved in its definition, then there may be an additional performance overhead on the client due to the construction process. In addition, the client must contain the business logic to manage the relationships between the components, which results in a more complex, larger client. When the client constructs the application model, the construction happens on the client side. Complex model construction can result in a significant performance overhead on the client side for clients with limited resources. Because the client is tightly coupled to the model, changes to the model require changes to the client. Furthermore, if there are different types of clients, it is more difficult to manage the changes across all client types. When there is tight coupling between the client and model implementation, which occurs when the client has direct knowledge of the model and manages the business component relationships, then changes to the model necessitate changes to the client. There is the further problem of code duplication for model access, which occurs when an application has many types of clients. This duplication makes client (code) management difficult when the model changes. Forces Separation of business logic is required between the client and the server-side components. Because the model consists of distributed components, access to each component is associated with a network overhead. It is desirable to minimize the number of remote method calls over the network. The client typically needs only to obtain the model to present it to the user. If the client must interact with multiple components to construct the model on the fly, the chattiness between the client and the application increases. Such chattiness may reduce the network performance. Even if the client wants to perform an update, it usually updates only certain parts of the model and not the entire model. Clients do not need to be aware of the intricacies and dependencies in the model implementation. It is desirable to have loose coupling between the clients and the business components that implement the application model. Clients do not otherwise need to have the additional business logic required to construct the model from various business components. Solution Use a Transfer Object Assembler to build the required model or submodel. The Transfer Object Assembler uses Transfer Objects to retrieve data from various business objects and other objects that define the model or part of the model. The Transfer Object Assember constructs a composite Transfer Object that represents data from different business components. The Transfer Object caries the data for the model to the client in a single method call. Since the model data can be complex, it is recommended that this Transfer Object be immutable. That is, the client obtains such Transfer Objects with the sole purpose of using them for presentation and processing in a read-only manner. Clients are not allowed to make changes to the Transfer Objects. When the client needs the model data, and if the model is represented by a single coarse-grained component (such as a Composite Entity), then the process of obtaining the model data is simple. The client simply requests the coarse-grained component for its composite Transfer Object. However, most real-world applications have a model composed of a combination of many coarse-grained and fine-grained components. In this case, the client must interact with numerous such business components to obtain all the data necessary to represent the model. The immediate drawbacks of this approach can be seen in that the clients become tightly coupled to the model implementation (model elements) and that the clients tend to make numerous remote method invocations to obtain the data from each individual component. In some cases, a single coarse-grained component provides the model or parts of the model as a single Transfer Object (simple or composite). However, when multiple components represent the model, a single Transfer Object (simple or composite) may not represent the entire model. To represent the model, it is necessary to obtain Transfer Objects from various components and assemble them into a new composite Transfer Object. The server, not the client, should perform such "on-the-fly" construction of the model. 2.2.6. Value List Handler—值列表处理器模式 Context The client requires a list of items from the service for presentation. The number of items in the list is unknown and can be quite large in many instances. Problem Most Java 2 Platform, Enterprise Edition (J2EE) applications have a search and query requirement to search and list certain data. In some cases, such a search and query operation could yield results that can be quite large. It is impractical to return the full result set when the client's requirements are to traverse the results, rather than process the complete set. Typically, a client uses the results of a query for read-only purposes, such as displaying the result list. Often, the client views only the first few matching records, and then may discard the remaining records and attempt a new query. The search activity often does not involve an immediate transaction on the matching objects. The practice of getting a list of values represented in entity beans by calling an ejbFind() method, which returns a collection of remote objects, and then calling each entity bean to get the value, is very network expensive and is considered a bad practice. There are consequences associated with using Enterprise JavaBeans (EJB) finder methods that result in large results sets. Every container implementation has a certain amount of finder method overhead for creating a collection of EJBObject references. Finder method behavior performance varies, depending on a vendor's container implementation. According to the EJB specification, a container may invoke ejbActivate() methods on entities found by a finder method. At a minimum, a finder method returns the primary keys of the matching entities, which the container returns to the client as a collection of EJBObject references. This behavior applies for all container implementations. Some container implementations may introduce additional finder method overhead by associating the entity bean instances to these EJBObject instances to give the client access to those entity beans. However, this is a poor use of resources if the client is not interested in accessing the bean or invoking its methods. This overhead can significantly impede application performance if the application includes queries that produce many matching results. Forces The application client needs an efficient query facility to avoid having to call the entity bean's ejbFind() method and invoking each remote object returned. A server-tier caching mechanism is needed to serve clients that cannot receive and process the entire results set. A query that is repeatedly executed on reasonably static data can be optimized to provide faster results. This depends on the application and on the implementation of this pattern. EJB finder methods are not suitable for browsing entire tables in the database or for searching large result sets from a table. Finder methods may have considerable overhead when used to find large numbers of result objects. The container may create a large number of infrastructure objects to facilitate the finders. EJB finder methods are not suitable for caching results. The client may not be able to handle the entire result set in a single call. If so, the client may need server-side caching and navigation functions to traverse the result set. EJB finder methods have predetermined query constructs and offer minimum flexibility. The EJB specification 2.0 allows a query language, EJB QL, for container-managed entity beans. EJB QL makes it easier to write portable finders and offers greater flexibility for querying. Client wants to scroll forward and backward within a result set. Solution Use a Value List Handler to control the search, cache the results, and provide the results to the client in a result set whose size and traversal meets the client's requirements. This pattern creates a ValueListHandler to control query execution functionality and results caching. The ValueListHandler directly accesses a DAO that can execute the required query. The ValueListHandler stores the results obtained from the DAO as a collection of Transfer Objects. The client requests the ValueListHandler to provide the query results as needed. The ValueListHandler implements an Iterator pattern [GoF] to provide the solution. 2.2.7. Service Locator—服务定位器模式 Context Service lookup and creation involves complex interfaces and network operations. Problem J2EE clients interact with service components, such as Enterprise JavaBeans (EJB) and Java Message Service (JMS) components, which provide business services and persistence capabilities. To interact with these components, clients must either locate the service component (referred to as a lookup operation) or create a new component. For instance, an EJB client must locate the enterprise bean's home object, which the client then uses either to find an object or to create or remove one or more enterprise beans. Similarly, a JMS client must first locate the JMS Connection Factory to obtain a JMS Connection or a JMS Session. All Java 2 Platform, Enterprise Edition (J2EE) application clients use the JNDI common facility to look up and create EJB and JMS components. The JNDI API enables clients to obtain an initial context object that holds the component name to object bindings. The client begins by obtaining the initial context for a bean's home object. The initial context remains valid while the client session is valid. The client provides the JNDI registered name for the required object to obtain a reference to an administered object. In the context of an EJB application, a typical administered object is an enterprise bean's home object. For JMS applications, the administered object can be a JMS Connection Factory (for a Topic or a Queue) or a JMS Destination (a Topic or a Queue). So, locating a JNDI-administered service object is common to all clients that need to access that service object. That being the case, it is easy to see that many types of clients repeatedly use the JNDI service, and the JNDI code appears multiple times across these clients. This results in an unnecessary duplication of code in the clients that need to look up services. Also, creating a JNDI initial context object and performing a lookup on an EJB home object utilizes significant resources. If multiple clients repeatedly require the same bean home object, such duplicate effort can negatively impact application performance. Let us examine the lookup and creation process for various J2EE components. The lookup and creation of enterprise beans relies upon the following: A correct setup of the JNDI environment so that it connects to the naming and directory service used by the application. Setup entails providing the location of the naming service and the necessary authentication credentials to access that service. The JNDI service can then provide the client with an initial context that acts as a placeholder for the component name-to-object bindings. The client requests this initial context to look up the EJBHome object for the required enterprise bean by providing the JNDI name for that EJBHome object. Find the EJBHome object using the initial context's lookup mechanism. After obtaining the EJBHome object, create, remove, or find the enterprise bean, using the EJBHome object's create, move, and find (for entity beans only). The lookup and creation of JMS components (Topic, Queue, QueueConnection, QueueSession, TopicConnection, TopicSession, and so forth) involves the following steps. Note that in these steps, Topic refers to the publish/subscribe messaging model and Queue refers to the point-to-point messaging model. Set up the JNDI environment to the naming service used by the application. Setup entails providing the location of the naming service and the necessary authentication credentials to access that service. Obtain the initial context for the JMS service provider from the JNDI naming service. Use the initial context to obtain a Topic or a Queue by supplying the JNDI name for the topic or the queue. Topic and Queue are JMSDestination objects. Use the initial context to obtain a TopicConnectionFactory or a QueueConnectionFactory by supplying the JNDI name for the topic or queue connection factory. Use the TopicConnectionFactory to obtain a TopicConnection or QueueConnectionFactory to obtain a QueueConnection. Use the TopicConnection to obtain a TopicSession or a QueueConnection to obtain a QueueSession. Use the TopicSession to obtain a TopicSubscriber or a TopicPublisher for the required Topic. Use the QueueSession to obtain a QueueReceiver or a QueueSender for the required Queue. The process to look up and create components involves a vendor-supplied context factory implementation. This introduces vendor dependency in the application clients that need to use the JNDI lookup facility to locate the enterprise beans and JMS components, such as topics, queues, and connection factory objects. Forces EJB clients need to use the JNDI API to look up EJBHome objects by using the enterprise bean's registered JNDI name. JMS clients need to use JNDI API to look up JMS components by using the JNDI names registered for JMS components, such as connection factories, queues, and topics. The context factory to use for the initial JNDI context creation is provided by the service provider vendor and is therefore vendor- dependent. The context factory is also dependent on the type of object being looked up. The context for JMS is different from the context for EJB, with different providers. Lookup and creation of service components could be complex and may be used repeatedly in multiple clients in the application. Initial context creation and service object lookups, if frequently required, can be resource-intensive and may impact application performance. This is especially true if the clients and the services are located in different tiers. EJB clients may need to reestablish connection to a previously accessed enterprise bean instance, having only its Handle object. Solution Use a Service Locator object to abstract all JNDI usage and to hide the complexities of initial context creation, EJB home object lookup, and EJB object re-creation. Multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility. This pattern reduces the client complexity that results from the client's dependency on and need to perform lookup and creation processes, which are resource-intensive. To eliminate these problems, this pattern provides a mechanism to abstract all dependencies and network details into the Service Locator. 2.3. 集成层模式 2.3.1. Data Access Object—数据访问对象模式 Context Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation. Problem Many real-world Java 2 Platform, Enterprise Edition (J2EE) applications need to use persistent data at some point. For many applications, persistent storage is implemented with different mechanisms, and there are marked differences in the APIs used to access these different persistent storage mechanisms. Other applications may need to access data that resides on separate systems. For example, the data may reside in mainframe systems, Lightweight Directory Access Protocol (LDAP) repositories, and so forth. Another example is where data is provided by services through external systems such as business-to-business (B2B) integration systems, credit card bureau service, and so forth. Typically, applications use shared distributed components such as entity beans to represent persistent data. An application is considered to employ bean-managed persistence (BMP) for its entity beans when these entity beans explicitly access the persistent storage-the entity bean includes code to directly access the persistent storage. An application with simpler requirements may forego using entity beans and instead use session beans or servlets to directly access the persistent storage to retrieve and modify the data. Or, the application could use entity beans with container-managed persistence, and thus let the container handle the transaction and persistent details. Applications can use the JDBC API to access data residing in a relational database management system (RDBMS). The JDBC API enables standard access and manipulation of data in persistent storage, such as a relational database. The JDBC API enables J2EE applications to use SQL statements, which are the standard means for accessing RDBMS tables. However, even within an RDBMS environment, the actual syntax and format of the SQL statements may vary depending on the particular database product. There is even greater variation with different types of persistent storage. Access mechanisms, supported APIs, and features vary between different types of persistent stores such as RDBMS, object-oriented databases, flat files, and so forth. Applications that need to access data from a legacy or disparate system (such as a mainframe, or B2B service) are often required to use APIs that may be proprietary. Such disparate data sources offer challenges to the application and can potentially create a direct dependency between application code and data access code. When business components-entity beans, session beans, and even presentation components like servlets and helper objects for JavaServer Pages (JSP) pages --need to access a data source, they can use the appropriate API to achieve connectivity and manipulate the data source. But including the connectivity and data access code within these components introduces a tight coupling between the components and the data source implementation. Such code dependencies in components make it difficult and tedious to migrate the application from one type of data source to another. When the data source changes, the components need to be changed to handle the new type of data source. Forces Components such as bean-managed entity beans, session beans, servlets, and other objects like helpers for JSP pages need to retrieve and store information from persistent stores and other data sources like legacy systems, B2B, LDAP, and so forth. Persistent storage APIs vary depending on the product vendor. Other data sources may have APIs that are nonstandard and/or proprietary. These APIs and their capabilities also vary depending on the type of storage-RDBMS, object-oriented database management system (OODBMS), XML documents, flat files, and so forth. There is a lack of uniform APIs to address the requirements to access such disparate systems. Components typically use proprietary APIs to access external and/or legacy systems to retrieve and store data. Portability of the components is directly affected when specific access mechanisms and APIs are included in the components. Components need to be transparent to the actual persistent store or data source implementation to provide easy migration to different vendor products, different storage types, and different data source types. Solution Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source. 2.3.2. Service Activator—服务激发器模式 Context Enterprise beans and other business services need a way to be activated asynchronously. Problem When a client needs to access an enterprise bean, it first looks up the bean's home object. The client requests the Enterprise JavaBeans (EJB) component's home to provide a remote reference to the required enterprise bean. The client then invokes business method calls on the remote reference to access the enterprise bean services. All these method calls, such as lookup and remote method calls, are synchronous. The client has to wait until these methods return. Another factor to consider is the life cycle of an enterprise bean. The EJB specification permits the container to passivate an enterprise bean to secondary storage. As a result, the EJB container has no mechanism by which it can provide a process-like service to keep an enterprise bean constantly in an activated and ready state. Because the client must interact with the enterprise bean using the bean's remote interface, even if the bean is in an activated state in the container, the client still needs to obtain its remote interface via the lookup process and still interacts with the bean in a synchronous manner. If an application needs synchronous processing for its server-side business components, then enterprise beans are an appropriate choice. Some application clients may require asynchronous processing for the server-side business objects because the clients do not need to wait or do not have the time to wait for the processing to complete. In cases where the application needs a form of asynchronous processing, enterprise beans do not offer this capability in implementations prior to the EJB 2.0 specification. The EJB 2.0 specification provides integration by introducing message-driven bean, which is a special type of stateless session bean that offers asynchronous invocation capabilities. However, the new specification does not offer asynchronous invocation for other types of enterprise beans, such as stateful or entity beans. In general, a business service such as a session or entity bean provides only synchronous processing and thus presents a challenge to implementing asynchronous processing. Forces Enterprise beans are exposed to their clients via their remote interfaces, which allow only synchronous access. The container manages enterprise beans, allowing interactions only via the remote references. The EJB container does not allow direct access to the bean implementation and its methods. Thus, implementing the JMS message listener in an enterprise bean is not feasible, since this violates the EJB specification by permitting direct access to the bean implementation. An application needs to provide a publish/subscribe or point-to-point messaging framework where clients can publish requests to enterprise beans for asynchronous processing. Clients need asynchronous processing capabilities from the enterprise beans and other business components that can only provide synchronous access, so that the client can send a request for processing without waiting for the results. Clients want to use the message-oriented middleware (MOM) interfaces offered by the Java Messaging Service (JMS). These interfaces are not integrated into EJB server products that are based on the pre-EJB 2.0 specification. An application needs to provide daemon-like service so that an enterprise bean can be in a quiet mode until an event (or a message) triggers its activity. Enterprise beans are subject to the container life cycle management, which includes passivation due to time-outs, inactivity and resource management. The client will have to invoke on an enterprise bean to activate it again. The EJB 2.0 specification introduces a message-driven bean as a stateless session bean, but it is not possible to invoke other types of enterprise beans asynchronously. Solution Use a Service Activator to receive asynchronous client requests and messages. On receiving a message, the Service Activator locates and invokes the necessary business methods on the business service components to fulfill the request asynchronously. The ServiceActivator is a JMS Listener and delegation service that requires implementing the JMS message listener-making it a JMS listener object that can listen to JMS messages. The ServiceActivator can be implemented as a standalone service. Clients act as the message generator, generating events based on their activity. Any client that needs to asynchronously invoke a business service, such as an enterprise bean, may create and send a message to the Service Activator. The Service Activator receives the message and parses it to interpret the client request. Once the client's request is parsed or unmarshalled, the Service Activator identifies and locates the necessary business service component and invokes business methods to complete processing of the client's request asynchronously. The Service Activator may optionally send an acknowledgement to the client after successfully completing the request processing. The Service Activator may also notify the client or other services on failure events if it fails to complete the asynchronous request processing. The Service Activator may use the services of a Service Locator to locate a business component. See "Service Locator" on page 368.