J2EE Design Patterns

核心提示：什么是Design Patten?简单来说，Design Patten 就是一个常用的方案，J2EE Design Patterns， 在我们的开发过程中，经常会碰到一些相同或者相近的问题，为了实现一个完整的流程，客户端必须访问账户EJB来完成一系列适当的工作，每次我们都会去寻找一个新的解决方法，为了节省时间提高效率

　　什么是Design Patten?
　　简单来说，Design Patten 就是一个常用的方案。 在我们的开发过程中，经常会碰到一些相同或者相近的问题，每次我们都会去寻找一个新的解决方法，为了节省时间提高效率，我们提供一些能够解决这些常见问题的，被证实可行的方案，构成一个统一的资源库。
　　一个Design Patten描述了一个被证实可行的方案。这些方案非常普通，是有完整定义的最常用的模式。 这些模式可以被重用，有良好的伸缩性，而这些Design Patten的优势将在设计J2EE应用时得到体现。
　　
　　1. Model-View-Controller
　　a. 问题
　　假如开发一个企业级应用，只需要一种客户端的话，那么一切都非常轻易解决。但真实情况是，我们必须面对运行在各种设备上客户端，象PDA，WAP浏览器以及运行在桌面上的浏览器，我们不得不开发不同的应用程序来处理来自不同客户端的请求。数据访问与现实将混淆在一起，可能会出现重复的数据访问，导致整个开发周期没有必要的延长。
　　
　　b. 建议的解决方法
　　Model-View-Controller (MVC) 开发模式被证实是有效的处理方法之一。它可以分离数据访问和数据表现。你可以开发一个有伸缩性的，便于扩展的控制器，来维护整个流程。如图1所示为整个模式的结构。MVC模式可以被映射到多层企业级的J2EE应用上。
　　§ 所有的企业数据以及商业逻辑可以作为模式。
　　§ 视图可以通过模式访问数据，并根据客户端的要求来显示数据。视图必须保证当模式改变的时候，数据显示也必须同时改变。
　　§ 控制器用来结合模式和视图，把客户端来的请求转换成模式能够理解并执行的请求，并且根据请求以及执行结果来决定下一次显示那一个视图。
　　根据以上的逻辑，你可以象这样建立一个应用：
　　§ 应用的商业逻辑由MVC中的模式也就是EJB来表现。模式必须处理由控制器传递过来的对数据的访问请求。
　　§ 多个页面组成了MVC中的视图，这些视图必须随模式一起更新。
　　§ 控制器是一系列接收用户动作的对象，他们把用户的请求转换成模式可理解的请求，并决定显示那一个页面当模式处理完请求后。
　　
　　c. 要点
　　§ MVC结构适用于那些多用户的，可扩展的，可维护的，具有很高交互性的系统。
　　§ MVC可以很好的表达用户的交互和系统模式。
　　§ 很方便的用多个视图来显示多套数据，是系统很方便的支持其他新的客户端类型。
　　§ 代码重复达到最低。
　　§ 由于分离了模式中的流控制和数据表现，可以分清开发者的责任，另外，也可以加快产品推向市场的时间。
　　
　　2. Front Controller
　　a. 问题
　　MVC给出了一个整个应用的松散的耦合架构。现在来看一下这样一个经常发生的情况。在某一个应用中，用户看到的视图和他所做的操作密切相关。这是一些具有高度交互性的页面，而这些页面之间含有高度的依靠性。在没有任何模式的时候，这个应用只是一个许多独立的页面的集合，维护和扩展变得异常困难。
　　§ 当一个页面移动后，其他含有这个页面链接的文件，都必须修改。
　　§ 当有一系列页面需要口令保护时，许多配置文件需要修改，或者页面需要包含新的标记。
　　§ 当一个页面需要一个新的表示层时，页面中的标记要被重新安排。
　　当这个系统变得复杂时，这些问题将变得更糟。假如用MVC来解决的话，就变成一个如何治理控制器和视图之间交互的问题。
　　
　　b. 建议的解决方法
　　前台控制模式可以解决这个问题。这个模式中，所有的请求都被传送到一个对象中。这个主要的对象将处理所有的请求，决定以后显示那一个视图，以及实现必要的安全需求。对于把视图显示以及其他功能实现集中到一个主要的对象中，将使修改变得很轻易，对应用的修改，可以在所有视图中反映出来。
　　
　　c. 要点
　　§ 这个模式对于需要在多个含有动态数据的页面之间进行复杂导航的系统来说，是很有效的。
　　§ 这个模式对于要在所有页面中都包含模板，转换等的应用来说，也是很有效的。
　　§ 由于视图的选择集中在前端控制器上，因此，视图的导航变得更加轻易理解和便于配置。
　　§ 视图重用和变更会更加轻易。
　　§ 视图之间的复杂交互，使得控制器变得复杂。从而，当应用发展的时候，控制器将变得难以维护。不过，大部分情况下可以用xml映射来解决。
　　§ 实现应用要求的安全性检验变得很简单。
　　§ 这个模式不适合小型的，只显示静态内容的应用。
　　
　　d. 样例
　　§ RequestMappings.xml 文件映射了传入的请求，处理器以及下一个页面
　　
　　useRequestHandler="true"
　　requiresSecurityCheck="true"
　　nextScreen="screen2.jsp">
　　com.blah1.blah2.blah3.request1Handler
　　
　　以上这个文件是控制器的指定配置，控制器的代码如下：
　　§ FrontControllerImpl.java 利用上面的XML实现了控制器
　　// all required imports
　　// exceptions to be caught apPRopriately wherever applicable
　　
　　public class FrontControllerImpl extends HttpServlet {
　　
　　// all required declarations, definitions
　　private HashMap requestMappings;
　　
　　public void init() {
　　// load the mappings from XML file into the hashmap
　　}
　　
　　public void doPost(HttpServletRequest request,
　　HttpServletResponse response)
　　throws IOException, ServletException
　　{
　　doGet(request, response);
　　}
　　
　　public void doGet(HttpServletRequest request, HttpServletResponse response)
　　throws IOException, ServletException {
　　String currentPage= request.getPathInfo();
　　// get all mapping info for "currentPage" from the hashmap
　　// if "securityCheckRequired = true", do the security check
　　// if "useRequestHandler = true", pass on the incoming request to the specified handler
　　// forward the results to the given "nextScreen"
　　}
　　}
　　用这种方法实现的控制器将很轻易维护，当应用有新的变动的时候，只要修改XML文件就能解决了。前台控制模式将使在视图和控制器之前有复杂交互的J2EE应用变得简单。
　　
　　3. session Facade
　　a. 问题
　　前台控制给出了一个基于MVC的，能有效治理用户与J2EE应用之间进行的复杂交互。这个模式可以使处理页面的现实顺序和用户的并发请求变得简单。并且使增加和改变页面现实变得更加轻易。
　　另外一个常见的问题是，当EJB或者业务逻辑发生变化的时候，应用的客户端也必须随之改变。我们来看一下这个问题。
　　一般来说，为了表现一个账户中的用户，我们使用一个业务逻辑来表示账户中的信息，象用户名和口令，再用一个EJB来治理用户的个人信息，象爱好，语言等。当要创建一个新的账号或者修改一个已经存在的账号时，必须访问包含账号信息的EJB，读取个人信息，修改并且保存，这样的一个流程。
　　当然，这只是一个非常简单的例子，实际情况可能比这个复杂的多，象查看用户定制了哪些服务，检验客户信用卡的有效性，存放订单等。在这个案例中，为了实现一个完整的流程，客户端必须访问账户EJB来完成一系列适当的工作。下面的例子显示了一个Servlet客户端如何来控制一个用户订单。
　　A servlet that does the workflow required for placing an order
　　// all required imports;
　　// exceptions to be caught appropriately wherever applicable;
　　// This servlet assumes that for placing an order the account and
　　// credit status of the customer has to be checked before getting the
　　// approval and committing the order. For simplicity, the EJBs that
　　// represent the business logic of account, credit status etc are
　　// not listed
　　
　　public class OrderHandlingServlet extends HttpServlet {
　　
　　// all required declarations, definitions
　　
　　public void init() {
　　// all inits required done here
　　}
　　
　　public void doPost(HttpServletRequest request, HttpServletResponse response)
　　throws IOException, ServletException {
　　// other logic as required
　　// Get reference to the required EJBs
　　InitialContext ctxt = new InitialContext();
　　Object obj = ctxt.lookup("java:comp/env/ejb/UserAccount");
　　UserAccountHome acctHome = (UserAccountHome)
　　PortableRemoteObject.narrow(obj, UserAccountHome.class);
　　UserAccount acct = acctHome.create();
　　obj = ctxt.lookup("java:comp/env/ejb/CreditCheck");
　　CreditCheckHome creditCheckHome = (CreditCheckHome)
　　PortableRemoteObject.narrow(obj, CreditCheckHome.class);
　　CreditCheck credit = creditCheckHome.create();
　　obj = ctxt.lookup("java:comp/env/ejb/Approvals");
　　ApprovalsHome apprHome = (ApprovalsHome)
　　PortableRemoteObject.narrow(obj, ApprovalsHome.class);
　　Approvals appr = apprHome.create();
　　obj = ctxt.lookup("java:comp/env/ejb/CommitOrder");
　　CommitOrderHome orderHome = (CommitOrderHome)
　　PortableRemoteObject.narrow(obj, CommitOrderHome.class);
　　CommitOrder or