Core J2EE Pattern:拦截过滤器

问题：

要在请求被处理之前，之后拦截并过滤操作一个请求和它的响应。

所谓请求的预处理和后处理，是指在请求的核心处理操作起之前、之后进行的操作。有些操作决定了处理过程是否还要继续，另一些则把输入输出数据流转化成合适进一步的形式。比如：

• 客户端是否有一个有效的会话？
• 请求的目录路径是否违反了限制条件？
• 系统是否支持客户端的浏览器类型？
• 客户端是用哪一种编码方式发送数据的？
• 请求数据流是否加密？是否压缩？

对于这些（以及其他很多）请求处理过程，一种常见的处理思路是用一长串的条件检查实现，通常会有嵌套的if/else语句来控制执行的流程。但是，既然在每个处理语句中执行的都是相似的操作，就会生成许多重复的代码。这样进行预处理和后处理导致代码质量脆弱、满是复制-粘贴份各国的程序，因为控制流程以及特定的处理操作和应用逻辑混在了一起。

而且这样的做法还会加大预处理/后处理组件与核心应用处理代码之间的耦合。

约束

• 要再多个请求之间实现集中，通用的处理过程，比如检查每个请求的数据编码方式、为每个请求留下日志信息或压缩输出响应。
• 要在预处理/后处理组件与请求处理核心服务之间实现松耦合，这样在加入/删除预处理/后处理操作就很容易，不会干扰核心服务。
• 要是预处理/后处理组建之间相互独立，每个组件都能自足存在，从而增进重用。

解决方案

使用拦截过滤器，作为一个可插拔式的过滤器，实现请求、响应的预处理和后处理。另有一个过滤器管理器，负责把各个处于松耦合关系的过滤器结合成一个链，并把控制一次委派给合适的过滤器。这样一来，不必改动现有代码就能够以各种方式加入、删除、合并这些过滤器。

策略

标准过滤器策略

定制过滤器策略

基本过滤器策略

模版过滤器策略

Web Service 消息处理策略

定制SOAP过滤器策略

JAX-RPC过滤器策略

 

效果

• 利用松耦合的处理起实现控制集中化
• 增进了重用
• 能灵活地通过声明配置
• 不便于信息共享