我看的资料和这幅图有一些出入。

资料要去这里找：http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

?

表现层模式：

?

拦截过滤器：Intercepting Filter。正如图中的“Apply zero or more”和Servlet规范所述一样，应当具备一个链式结构。这个链式结构中的每个filter，互相之间应当是一个互不依赖的松耦合关系，以便于容易地组合。

?

前端控制器：Front Controller。给表现层请求安排一个集中访问点。集中了控制逻辑，一定程度避免了重复代码。和拦截过滤器的区别：拦截过滤器使用的是松耦合的，结合成链式的处理器逻辑，适合进行强大的预处理、后处理的策略分布；而前端控制器则专注于集中控制，减少视图中的业务和处理逻辑，提高重用度。

在常用的Struts网站构架中，N个拦截器都是可以自由组合的，也可以自定义合适的拦截器栈来继承某个通用的基础拦截器栈，一些通用的拦截逻辑变放置在基础拦截器栈中，这里是一个拦截过滤器和前端控制器结合实现的例子。

?

Context对象：不想在与协议无关的环境上下文中使用针对特定协议的系统信息。就是说系统信息，比如请求、配置和安全数据等等，这些东西，通常应当被隐藏起来，不能被业务逻辑看到；但是在某些情形下，业务组件可能又必须用到这些信息，例如，进行终端适配的组件，需要用到HTTP报文中的一些header，那么直接使用会导致组件的灵活性和可重用性的下降，导致前一篇我提到的表现层数据结构和业务层的紧耦合。

解决方法就是制定一个特定的API，将业务组件需要的部分通过API来包装和筛选，而不是直接把表现层数据结构直接暴露给它。这样一来，对于表现层的一些改变，比如协议等方面的改变，不会直接影响到业务组件的接口和运行，只需要修正API的实现逻辑。

还有个什么好处？如果我需要测试业务层的逻辑，因为有了这样一层特殊的API，我可以把整个表现层mock掉。

这里有一个应用例子就是RequestContext对象，API只传输这个，而不是具体的某一Request对象，对于复杂的请求层面被隔离掉，留下一个包装好的上下文给后面的逻辑。

?

应用控制器：集中地、模块化地进行操作管理和视图管理。

操作管理：把输入请求解析到一个操作（action），让它处理该请求。

视图管理：选定返回给客户端的视图，并把请求分派到这个视图。

这两点的应用例子其实就是在struts-xxx.xml里面定义的配置，如同一个路标，对于出入视图层的数据进行方向上的导航。

举例来说，它的实现经常采用的策略是command对象的策略，命令对象的说法具体可见GoF的那本经典设计模式的书。

效果：把操