J2EE核心模式三

View Helper（视图协助器）

View Helper模式要求把业务处理逻辑从视图（View）里排除出去，也就是说，视图里只包含显示用代码，其余的代码则应该放在做为Helper Class（协助器）的业务逻辑层里。
View Helper（视图协助器）模式介绍

我们从问题，解决方法，策略，优点几个方面介绍View Helper（视图协助器）模式。最后给出View Helper的相关联结。

问题

一个需要动态取得并显示业务数据的WEB应用系统的开发中，存在的一般问题是，在视图（view）层同时混在着业务逻辑处理代码和页面表示（presentation）代码。这样会存在各种问题：

1，柔软性

2，重用性

3，可维护性

4，角色的独立性

图1：view里混在业务逻辑处理代码与表示代码

解决方法

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.

使用View Helper，把业务处理逻辑从视图（View）里排除出去，视图里只包含显示用代码，其余的代码则放在做为Helper Class（协助器）的业务逻辑层里。Helper Class可以是JavaBean或自定义标签。

如图：

图2：使用Helper类把业务逻辑处理从View里分离开来。

View：为Client提供表现/显示的信息。可以是JSP或SERVLET。

Helper：协助view或controller完成它们的处理。因此Helper担当着很多种职责：

- 收集view所要求的数据

- 保持交互中间数据模型

- 对数据库等的访问

- 数据模型的优化

等。一个Helper可以是JavaBean或自定义标签等。

策略

View Helper模式可以有多种实现策略：

JSP View Strategy
    JSP作为View。

Servlet View Strategy
    Servlet作为View。

JavaBean Helper Strategy
    JavaBean Helper策略

Custom Tag Helper Strategy
    自定义标签Helper策略

Business Delegate as Helper Strategy
    Helper被实现为Business Delegate。

Transformer Helper Strategy
    Helper被实现为eXtensible Stylesheet Language Transformer（XSLT）。

等，一般推荐使用JSP作为view，JSP里面不包含任何script。Helper类可以用JavaBean与自定义标签实现。

STRUTS里的Form类与JSF里的managed-bean，以及相当于这里的Helper类。

优点：

使用View Helper模式有以下好处：

- 提高应用程序的模块化，可重用性，以及可维护性

- 提高角色的独立性。有利于让项目组人员分工合作，分别负责应用程序的不同部分
参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - View Helper
Front Controller（前端控制器）

Front Controller模式要求在WEB应用系统的前端（Front）设置一个入口控制器（Controller），所有的request请求都被发往该控制器统一处理。Front Controller一般可以用来做一个共通处理比如认证，页面导航，Session管理，国际化或本地化处理等。
Front Controller（前端控制器）模式介绍

我们从问题，解决方法，策略，优点几个方面介绍Front Controller（前端控制器）模式。最后给出Front Controller的实现范例以及相关联结。

问题

我们使用一个模式，都是为了解决某些问题而使用的。Front Controller模式用来解决什么问题呢？

我们在开发WEB应用系统（但不拘于WEB应用）时，存在很多不恰当的设计方法，比如让客户端（Client，一般指浏览器）可以直接访问各个视图（view，JSP等）。这样逻辑被分散到各个视图中，从而产生了各种问题：

1，对已有的功能修改困难，可维护性低。假如session管理，一旦session内容需要发生改变，则需要修改所有view中的相关代码。

2，很难增加新的功能，缺乏可扩展性。例如，我们需要在已有的系统中加入安全控制功能，控制用户对某些页面的访问，因为没有统一的处理入口，我们需要在所有的view中都加上认证代码。

对于系统中需要提供的类似以下功能：
认证
页面导航与转发等
Session管理
国际化或本地化处理
日志
其它共通处理
等，都会存在代码分散重复，可维护性低，缺乏可扩展性等问题。

图1：相同的逻辑被重复分散在各个view里。

解决方法

使用Front Controller，强制分离view的显示逻辑与业务处理逻辑。如图：

图2：前端控制器

Controller作为所有request的最初访问点。

策略

Front Controller模式可以有多种实现策略：

Servlet（+ Dispatcher，+Command，+…）Front Controller策略

Filter Controller策略

JSP Front Controller策略

等，一般推荐使用前2种实现方法。

优点：

使用Front Controller模式有以下好处：

- 集中控制

- 提高可管理性和安全控制能力

- 提高可重用性可扩展性

范例

下面是一个Servlet Controller的实现范例。该范例让doPost与doGet方法调用processRequest方法，processRequest方法执行“认证”“session管理”等共通操作，同时结合Command模式调用了业务逻辑。

代码：

参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - Front Controller
Intercepting Filter（拦截过滤器）

Intercepting Filter模式使用一到多个过滤器（Filter）为采用拦截的方式为request/response（用户请求/服务器响应）做前处理以及后处理。Intercepting Filter一般可以用来做某些共通处理比如认证，页面导航，Session管理，国际化或本地化处理，日志等。
Intercepting Filter（拦截过滤器）模式介绍

我们从问题，解决方法，策略，优点几个方面介绍Intercepting Filter（拦截过滤器）模式。最后给出Intercepting Filter的实现范例以及相关联结。

问题

表示层的请求（request）处理机制收到很多不同种类的来自客户端的请求，有些请求只是简单地被发送给目标组件，但另外一些请求必须作某些加工处理。

问题：

根据不同的状况，可能有必要对request/response做一些前处理和后处理。请确认你的应用中是否需要以下处理：

1，客户端被认证过吗？

2，客户端是否有一个正确的session？

3，客户端的IP地址是否来自一个被信任的网络？

4，request地址是否没有违反任何约束？

5，发送数据的时候客户端使用何种编码？

6，我们是否支持客户的浏览器？

等等。

因为这些原因，客户的请求在得到真正的处理或回应之前，我们的应用系统需要对它做种种判断和处理，然后决定怎么样处理或应答来自客户端的请求。

这些判断及相应处理应该在什么地方通过什么方法进行呢？

一个典型的实现方法是包含一系列的条件判断语句（比如 if/else），当任何条件失败时则退出后续处理。但这种解决方案导致代码的脆弱性以及容易产生copy-and-paste风格的程序代码，而且当条件发生改变（修改或增减条件）时，不得不修改原有的代码。

解决方法

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.

用一个标准的方式，来创建插件式（pluggable）的过滤器做某些共通处理，使用这种方式，无需改变核心的请求处理代码。这些过滤器通过对输入（request）输出（response）进行拦截，做一些前处理/后处理操作。我们能够简单地增加/移除这些过滤器而无需对原有的代码做任何修改。

Intercepting Filter模式常被用来解决以下问题：
认证
页面导航与转发等
Session管理
国际化或本地化处理
日志
其它共通处理
等等。

Intercepting Filter的结构

如图：

FilterManager

FilterManager管理Filter的执行。它负责创建具有正确顺序的FilterChain，开始处理。

FilterChain

互相独立的Filter的集合。

FilterOne,FilterTwo,FilterThree

各个Filter，做request/response的前处理或后处理操作，由FilterChain协调它们的处理。

Target

客户端请求的目标资源。

策略

Intercepting Filter模式有多种实现策略：

2种基本策略

Custom Filter Strategy（自定义Filter策略）

Standard Filter Strategy（标准Filter策略）

另外，在此基础之上，结合对象的抽象继承等方式，可以衍生出更加复杂的实现方法。比如Base Filter Strategy，Template Filter Strategy等。

Custom Filter Strategy（自定义Filter策略）

所谓自定义Filter策略，就是完全由自己实现Filter框架，包括FilterManager，FilterChain，以及各Filter等。实现方法请参考本文末尾给出的联结文章。

Standard Filter Strategy（标准Filter策略）

J2EE（SERVLET 2.3规范）已经为我们提供了标准的 Intercepting Filter模式的实现方法。在J2EE应用中，FilterManager与FilterChain由支持J2EE标准的WEB容器为我们实现，我们只需实现javax.servlet.Filter接口的类即可。

比如，Tomcat中，FilterManager角色的实现类是 org.apache.catalina.core.StandardWrapperValve，FilterChain角色的实现类是 org.apache.catalina.core.ApplicationFilterChain。由于它们支持J2EE标准，我们无需关心它们的实现细节。

优点：

使用Intercepting Filter模式有以下好处：

- 不同的功能由不同的Filter类实现，它们被松耦合地组织在一起，由FilterManager以及FilterChain集中控制。

- 提高可重用性。各Filter之间完全独立，各Filter可不加修改地分别用于不同的应用中，具有完全地可重用性。

- 高度可扩展性。通过配置文件管理Filter的增减以及与目标资源的对应关系，可以无需修改代码便可增加/移除Filter。

但由于它们之间松耦合性，它们之间的信息共享花费的代价比较高。

范例

Intercepting Filter模式标准Filter策略的实现比较简单，只需要实现javax.servlet.Filter接口，然后在web.xml里加以设置即可。介绍这方面的文章很多，文末给出的联结也有具体的实现方法，这里不再详述。

相关模式

ront Controller（J2EE核心模式的前台控制器模式）

Controller与Intercepting Filter解决类似的问题。但Controller更适合控制核心处理。

Decorator [GoF] （GoF装饰模式）

Intercepting Filter模式可以使用GoF的Decorator模式来实现，该实现方法提供动态插件式的封装行为。

Template Method [GoF]（GoF模板方法模式）

可以使用GoF模板方法模式实现Filter模板（the Template Filter Strategy）。

Interceptor [POSA2]

The Intercepting Filter pattern is related to the Interceptor pattern, which allows services to be added transparently and triggered automatically.

Pipes and Filters [POSA1]

The Intercepting Filter pattern is related to the Pipes and Filters pattern.
参考资料：

Core J2EE Pattern Catalog

Core J2EE Patterns - Intercepting Filter