四、 Spring不象Webwork2或tapestry那样去隐藏Servlet相关的元素如HttpServletRequest或HttpServletResponse

　　这又是一个重要的设计决定。在Webwork2里我们没有HttpServletRequest或者HttpServletResponse，只有getter， setter或ActionContext里数据，这样的结果导致一个干净的Action，一个与Web完全无关的Action，一个可以在任何环境下独立运行的bean.那么Webwork2的这样一个基于Command模式的Action究竟给我们带来了什么？我想主要有两点：

　　1、 它使我们的Action可以非常容易地被测试。

　　2、 用户可以在Action里添加业务逻辑，并被其它类重用。

　　然而仔细跟Spring比较一下，我们就会发现这两点功能所带来的好处其实并不象我们想象的那么显着。Spring的Controller类也可以非常轻松被测试，看一下spring-mock下面的包吧，它提供的MockHttpServletRequest， MockHttpServletResponse还有其它一些类让测试Controller变得异常轻松。再看一下Action里的业务逻辑吧，Jason Carreira曾经说我们可以尽情地在Webwork2的Action里加业务逻辑，因为Action是不依赖于Web的。但是有多少人真正往Action里加业务逻辑的？大多数人都会业务逻辑delegate给另一个Service类或Manager类。因为我们很清楚，往Action里加业务逻辑会使整个体系的分层架构变得不清晰，不管怎样，Web层就是Web层，业务层就是业务层，两者的逻辑混在一起总会带来问题的。而且往Action里加业务逻辑会使用这个Action类变得庞大，Webwork2的Action是每个request都创建实例的，尽管带来的性能影响不太大，但并不表示每次都要把业务逻辑再new出来，业务逻辑在大多数的情况下应该是单例的。

　　不把request和response展现给用户当然还会带来功能上的损失，也许一般的场合，用用webwork2提供的接口已经足够了，但有时我们必须要知道request和response才能发挥出更大的威力。比如我以前的一个项目里有一个通过递归动态生成的树状结构的页面，在jsp页面上显示递归是痛苦或不可能的，因此我用response直接write出页面，这在spring里很easy，但在webwork里可能比较难了（偶不敢肯定，偶研究得不够深，也许高手是有办法的）。

　　五、 Spring提供了不错但不够充分的interceptor机制

　　回头看一下struts，它在架构里甚至没有给我们提供hook point的机会，我们没有任何机会加入自己的interceptor.我们只能通过重载struts的RequestProcessor类来进行一点有限的扩展。

　　到了Webwork2，似乎interceptor一下子成了整个Framework的核心，除了Action的核心部件，其它所有的东西都是interceptor.它的超强的interceptor功能使们扩展整个架构变得非常方便。有人称这种interceptor为AOP，Jason Carreira则自豪地宣称这个叫做pragamtic AOP.我不认同这是AOP，它只是简单的interceptor机制。但不管如何，它的interceptor确实有强大的功能。

　　Spring也提供了它的interceptor机制，它的HandlerInterceptor三个interceptor方法：peHandle， postHandle， afterCompletion.分别对应Controller执行前，Controller执行后和page render之后。虽然大多数情况下已经够用，但是从功能上来说显然它没有Webwork2强大。从AOP的角度来看，它没有提供around interceptor，而只有before与after interceptor.这意味着我们无法在interceptor前后保持状态，最简单的情况假如我们要计算一个Controller的执行时间，我们必须在执行完before后把begintime这个状态保持住，再在after里把它调出来，但是显然这个状态保持会是个问题，我们不能把它放到instance变量里，因为interceptor不是线程安全的。也许通过ThreadLocal可以解决这个问题，但是如此简单的功能要用到这样的方法来处理，显然这个Interceptor本身设计上还是有点问题的。

　　六、 Spring提供了MultiActionController，使它可以在一个类里包含多个Action

　　这个设计和struts的DispatchAction有点类似，只不过提供了更灵活的机制。当我们的项目变大的时候，把功能类似的方法放到同一个Action里完全值得的！Webwork2缺少这样的机制。假如看一下Spring的源代码，会发现其实实现MultiActionController的工作量相当的少，只不过是用反射机制把解析出来的方法名执行一下就完事了。其实Webwork2也完全可以提供这样的机制。虽然从设计上来说确实不是很优雅，但是它确实很有用。

　　七、 Spring提供了更多的选择方式

　　看看Spring里提供的Controller吧，它提供了好多不同的Controller类。要生成Wizard吗？要专门用于提交form的Controller吗？要执多个方法的类吗？Spring提供了丰富的子类来扩展这些选择。当然我们还可以很轻松地自己扩展这些功能。

　　再看看Spring的ViewResolver吧， 它提供了无数不同类型的ViewResolver.更重要的是我们自定义我们的页面映射方式。看看strtus，看看webwork2，都会存在页面与forward name的一层间接转换，我们必须在配置文件里配置好某个字符串（典型的是success）对应的是那个页面。但是Spring里我们有了更大的自由度，我们可以采用webwork2的策略，也可以采用更简单的策略，如将JSP文件名去掉扩展名的映射方法。也许有人认为这种映射方式很幼稚，但是我觉得它是非常有用的方式，即使在大项目里。

　　还有新的扩展吗？看看Spring Web Flow吧，它是SpringFramework的子项目。它为一长串的基于页面流的Wizard页面提供了可配置的实现方式。在Spring 1.3里，它将是SpringFramework的一部分。

　　八、 Spring的tag

　　尽管Spring的tag数量上少得可怜，但它却是精心设计的。它的目标很简单：让美工可以轻松地编辑页面。因为在Spring的页面里Text仍然是Text，checkbox仍然是CheckBox，而不象在struts或webwork2中的Tag.它只是用Springbind对输入内容进行了一下包装。所以尽管页面显示代码上会比Webwork2多，但这绝对是有价值的。

　　在接下来的几章里，我会分析一下Spring是如何让我们的Web应用不需要知道ApplicationContext就能够访问IOC容器的，然后会对Spring的设计和执行过程进行简单的源码分析，然后给出几个扩展Spring MVC的方法。