J2EE体系结构设计（上）

　　目前大多数企业采用J2EE技术的结构设计与解决方案。对于我们学习和研究J2EE体系结构来说，了解与掌握J2EE体系结构的设计方法及一些常用模式是必须的；模型-视图-控制(model-view-control，简称MVC)结构是目前最常见的J2EE应用所基于的体系结构，MVC主要适用于交互式的Web应用，尤其是存在大量页面及多次客户访问及数据显示；相比较而言，一个工作流体系结构更多应用于过程控制和较少交互的情况下；除了体系结构外，J2EE的设计模式对我们解决应用系统的设计也有很大的帮助。

一、J2EE的模型-视图-控制（MVC）体系结构 

 

模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。 
　　控制层负责定义应用程序的行为。它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。在Web应用中，它包括对Web层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。 

二、J2EE设计模式 
一个设计模式描述了对于特定设计问题被验证的解决方案，它综合了所有开发者对这个问题所在领域的知识和见解；同时也是对于常见问题的可重用方案，它们一般适用于单个问题，但是组织在一起就可以提供整个企业系统的解决方案。下面我们列举八种常用于J2EE平台的设计模式，并对每种模式作简单的介绍，便于大家学习、理解与灵活应用。
前控制器(front controller)主要提供一种可以集中式管理请求的控制器，一个前控制器可以接受所有的客户请求，将每个请求递交给相应的请求句柄，并适当地响应用户。

　　前控制器也是表示层的设计模式，它的出现主要是由于表示层通常需要控制和协调来自不同用户的多个请求，而这种控制机制又根据不同的需要，可能会集中式控制或分散式控制。换句话说，就是应用系统需要对于表示层的请求提供一个集中式控制模块，以提供各种系统服务，包括内容提取、视图管理和浏览，如果系统中没有这种集中式控制模块或控制机制，每个不同的系统服务都需要进行单独的视图处理，这样代码的重复性就会提高，致使系统开发代价提高；同时，如果没有一个固定模块管理视图之间的浏览机制，致使其浏览功能下放于每个不同的视图中，最终必将使得系统的可维护性受到破坏；中我们主要讨论的是集中式控制模块，而不是分散式控制，因为前者更适合于大型的应用系统。

　　基于上面所说的问题，研究人员提出了前控制器的设计模式。在这种模式中，控制器提供一个处理不同请求的控制点，这里的处理工作包括安全事务、视图选择、错误处理和响应内容的生成；通过将这些处理工作集中在一点进行，大大地减低了Java代码量，同时这种方法也可以减少在视图模块的程序逻辑，保证了在不同请求之间可以重用大量的逻辑代码。通常，控制器都是和一个分派组件联合工作的，分派组件主要是用于视图管理和浏览，也就是为用户选择下一个应该显示的视图，并同时提供对于相关显示资源的控制。分派组件可以包含在控制器之内，或是在另外一个单独的组件中；虽然前控制器模式推荐对于全部的请求使用统一处理，但是它也没有限制在一个系统中只能具有一个控制器，在系统中的每个层次都可以具有多个控制器，并且映射至不同的系统服务，下图2显示了前控制器的类图。 

 

图3显示了前控制器的序列图，表示一个控制器如何处理相关的请求。 
 

下面我们来讨论一下图3的各个组件。 
控制器(controller)是负责处理各种客户请求的控制点，并可以将一定的职能(如用户认证等)下放给帮助类。 

　　(2)帮助类(Helper)。帮助类负责帮助一个视图或控制器来完成其处理工作，因此，帮助类具有多项职责，包括收集数据、存储中间数据模型等；另外，帮助类也可以在保证数据完整性和准确性的情况下，为不同显示需求修改数据模型；也就是说，根据用户的请求，帮助类可以向视图提供未经处理的原始数据，或是已经格式化后的Web内容，一个视图同时可以和多个帮助类协同工作，而后者通常是由JavaBeans和标签(tag)实现的。 |||

3、视图   
1）基于Servlet前控制器 

　　2）基于JSP的前控制器 

　　3）控制器之中的分派组件 

　　4）基础前端 

　　5）用过滤器实现前控制器 

　　4、视图帮助 

　　这种设计模式的出现主要是由于目前的应用系统通常需要实时地开发显示内容，并且能处理动态的程序数据。如果这些程序数据的访问逻辑和显示逻辑的关系过于紧密，则系统的表示层就会经常需要改动，从而系统的灵活性、重用性会大大地受到破坏；同时在相同的模块中实现访问逻辑和显示逻辑将会影响系统的模块化，也会使得开发团队的任务划分不清。

　　一个视图通常包含格式化信息，并将其处理任务分发给自己的帮助类，后者通常是用JavaBeans或标记(tag)来实现的，帮助类同时可以存储视图的中间数据模型并实现数据适配器的功能，即适当地转化数据格式；开发人员可以采用多种方法实现视图组件，通常，开发人员可以使用JSP来实现，并且这也是一种值得推荐的方法。当然，相应地开发人员也可以使用Servlet来实现它，将视图中一定的程序逻辑植入到帮助类中，会有利于应用系统的模块化和可重用性。系统可以使用同一个帮助类为不同的用户显示不同的数据信息，并在不同的显示格式下显示；通常，如果开发人员发现视图的JSP页面中存在大量的脚本代码时，就可以考虑使用视图帮助这种模式了，因为在这种情况下，基本都是程序逻辑和显示逻辑具有过于紧密的联系；这时开发人员可以将一些适用于所有类型的请求的逻辑处理放置到一定的帮助类中，而根据需要，也可以将另外一些逻辑处理放置在视图层上的其他程序模块中，比如说以前讨论过的截取过滤器。 
视图帮助这种模式的设计理念主要是分离应用系统的逻辑职责，下面我们提供一些图示，以方便大家更好地理解这种模式。