J2EE设计模式浅谈(一)

J2EE设计模式浅谈
zhuam@studyjava.com
当我们纵观J2EE应用时，发现n-tier架构中已出现了许多新的技术和解决方法（design pattern）下面我参考 Sun Blueprints 的设计，简要的讲解design pattern下图来自
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
 

 

首先J2EE设计模式还在不断的发展，我以下所说的设计模式全按上图中的来说，一来可以给大家一个更好直观的效果，二来我的目的也只是让各位了解J2EE设计模式，希望可以达到一个抛砖引玉的效果。
在还没有进入正题之前我还想说几句，大家不要为了用design pattern而去用design pattern，最好根据自己的需求去选择适合自己项目的design pattern。
J2EE有两大类重要的J2EE模式，一类由Sun Java Center管理，定义15种模式，已经在《Core J2EE Patterns》书中发表，另一类是TheServerSide.Com,这种类发表了大量的模式，最重要的见《EJB Design Patterns: Advanced Patterns,Processes and Idioms》下面我们把design pattern分层说明
1、 表示层模式，用于Web组件层
2、 业务层模式，用于业务逻辑层
3、 数据集成层模式，连接DB Or EIS

Intercepting Filter(截获过滤)
提供请求预处理和后处理的方案，定义灵活的体系结构，可以声明对截获请求和响应进行过滤，在Servlet2.3中已经实现了Filter功能，该模式主要用于记录日志、看用户有没有LOGIN等等。
Front Controller(前端控制器)
通过中央控制器提供请求管理和处理。控制器取代通常发生在表示层的请求，从而取代模型试图控制器（MVC ，Model View Controller）模式的控制器部分，前端控制器管理内容的读取，导航。如上图，可看出Front Controller是系统的一个入口，由他调用相应的逻辑Bean，完成相应的处理工作后，更新视图View,在这里我还想提醒大家一下，有的应用把更新视图（View）的工作交给了相应的逻辑Bean来完成。
View Helper(视图帮助器)
将负责表示层的逻辑代码与其他的业务逻辑分开，表示格式放在视图组件中去，可能包括多个子组件，组成复杂视图。业务逻辑代码放在帮助器组件中。说白了就是让我们不要在视图（View）中写入业务逻辑代码，即少写一些Scriptlet。
Composite View(复合视图)
是从原子组件创建累计表示（View）的灵活方案。表示体系结构可以方便地组织基本视图组件，使表示灵活，还可以进行其他的工作，包括个性化和定制。
Dispatcher View(派遣视图)
类似于Service to Worker模式，是由Dispatcher组件与Front Controller和View Helper模式组合而成。它与Service-to-Worker模式不同的是，这个模式在进行视图处理期间进行请求处理，因此更适合小型应用程序。
Service to Worker（服务/工人）
它是由Dispatcher组件与Front Controller和View Helper模式组合而成，先进行请求处理再进行视图处理，适合用于大型应用。

由于Dispatcher View与Service-to-Worker有很多的相似之处，在此我做一下比较与说明，
1、 他们都是由表示层模式（Front Controller、View Helper）组合而成，参与者是控制器、派遣器、视图帮助器的组合。
2、 在Service-to-Worker模式中控制器、派遣器的功能很大，除了要处理客户请求，视图跳转，派遣器还要从业务层读取数据，视图负责表示派遣器读取数据，将更多的逻辑和行为移到Front Controller、Dispatcher、View Helper中简化视图（View）。
3、 而在Dispatcher View模式中控制器、派遣器的作用则很小，视图要负责从业务层读取内容和显示数据，它将更多的逻辑和行为交给了视图（View）使我们的视图变的很复杂，通常要用Scriptlet或Taglib完成控制器没有完成的任务。

模式的好处使得我们自己的系统具有好灵活性和可维护性，但同时也增加了系统的复杂性，下次我会接着说剩下的模式，不当之处请指正。