J2EE表现层模式--前端控制器

问题:

你想给表现层的请求处理安排一个集中访问点。

系统需要一个几种的访问点来处理请求。如果没有几种访问点,那么多个请求之间共用控制代码就会在许多文件中重复的出现<比如视图文件>中重复出现。如果控制代码和视图创建代码混在一起,整个应用系统的模块化程度和内聚性都要下降。另外,如果控制代码在多处散放,也不便于代码维护,只要代码有一处改动,就需要改动多个文件。

约束:

--你想要避免重复控制逻辑

--你想要对多个请求采取共同的处理逻辑。

--你想把系统处理代码和视图分隔开(不要在视图中写控制代码)

--你想要把系统的访问点集中在一点

解决方案:

使用给一个前端控制器,作为最初的接触点,用来处理所有相关的请求。前端控制器几种了控制逻辑,避免了逻辑的重复,完成了主要的请求处理操作。

前端控制器为处理请求提供了一个集中的入口点。因此能够集中控制逻辑,因此就减少了直接置入视图的代码量。

这个模式和拦截过滤器相似,因为两者都提取、合并了表现层的一些共同控制逻辑。一个主要区别在于:

拦截过滤器--提供了一组松耦合的、结成一条链的处理器,以及一些特别适合进行预处理和后处理的强大策略。

前端控制器--集中控制、减少视图的业务、处理逻辑,就能够提高多个请求之间代码的重用度,减少代码重复。除非视图中的代码微乎其微,否则使用前端控制器就要优于在多个视图中置于代码,因为后者是一种“复制-粘贴”的重用,这样的代码很脆弱。

另外,如果在多个视图置入代码,还会使团队中的每个开发者用不同的方法完成同样的任务--而这种处理本来是完全一致的,应该统一、规范的方式集中完成。比如,如果由每个开发者在页面中加入<tag:checkLogin/>标记,实现对特定页面的访问逻辑,那么就很难保证一直的效果,因为可能就有开发者忘了做这件事情。

前端控制器通常会使用应用控制器,后者负责操作和视图管理。

操作管理--也就是定位特定的操作action,并把控制权路由到该操作上、由他处理逻辑请求。

视图管理--则是找到合适的视图,并分配到该视图上。虽然这个任务也可以放进前端控制器完成,但是把它独立出来,成为应用控制器的一部分功能,能够增进模块化、可维护性和可重用性。

虽然处理相关请求的工作集中了,但是这并不意味着对系统中处理器数量做了任何的限制。一个最常见的做法是由一个前端控制器处理所有的请求,但是应用系统当然也可以有多个控制器,每个控制器对应于一类服务。

对于前面只使用一个控制器的通常的情况,服务器管理任务比较少,因为WEB服务器只需注册一个组件。这也意味着增加一种服务并不需要在web服务器上注册改服务。这减少了管理负担,更便于热部署,可以结合struts1.2来好好考虑。

而对于使用多控制器的情形,每个控制器都必须在web服务器上注册。增加一种服务也需要在web服务器上注册。

设计手记:处理请求

处理请求需要两种操作:请求处理和视图处理。在请求处理过程中,表现层中又必须进行几种操作:

--协议处理和上下文转换

--导航和路由

--核心处理

--分派

协议处理--是指处理与特定协议相关的请求,上下文转换是指吧与特定协议相关的状态转换成更具有通用的形式。一个例子是,从HttpServletRequest实例中获取参数,在复制到一个myRequest对象中,从而能够在servlet环境之外独立应用。

导航路由--是指一个特定的请求的路由,比如用哪些对象进行请求的核心处理,用哪个视图显示结果。

核心处理--对请求的实际处理

分派--是指把控制权从一个系统的一部分转交给另一个部分,比如从请求处理机制转交给视图处理组件。

策略:

--servlet前端策略

--JSP前端策略

--命令加控制器策略

--物理资源映射策略

--逻辑资源映射策略

--多路资源映射策略

--“控制器中的分配器”策略

效果:

--集中控制

--提高系统的可维护性

--增进了重用

--增进了开发团队中职责之间的区分

相关推荐