Webwork2的每个Action都是线程安全的。因为每过来一个request，它就创建一个Action对象。由于现代JDK垃圾收集功能的效率已经不成问题，所以这种创建完一个对象就扔掉的模式也得到了好多人的认可。Rod Johnson甚至以此为例证明J2EE提供的object pool功能是没多大价值的。
Struts 创建的是 Action 的单一实例，并允许多个线程调用它的 execute()。这使请求处理变得更快，因为框架处理每个请求时不用频繁地创建新的 Action 实例。但是因为可以在多个线程之间共享单一对象，所以必须遵守适当的线程注意事项，因为其他线程可能会破坏在这个动作中保持状态的实例变量。
Struts的设计者Craig R. McClanahan曾经说当时他设计struts时有两个条件不成熟：当时没有测试驱动开发的概念；当时JVM的垃圾收集性能太次。假如现在重新设计的话，他也会采用每个request生成一个新对象的设计方法，这样可以解决掉线程安全的问题了。
然而仔细跟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出来，业务逻辑在大多数的情况下应该是单例的。
回头看一下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前后保持状态.
这篇非原创，但也不某个具体作者写的，是我收集的多篇资料整理而成的，版权都属于原作者
Struts 创建的是 Action 的单一实例，并允许多个线程调用它的 execute()。这使请求处理变得更快，因为框架处理每个请求时不用频繁地创建新的 Action 实例。但是因为可以在多个线程之间共享单一对象，所以必须遵守适当的线程注意事项，因为其他线程可能会破坏在这个动作中保持状态的实例变量。
Struts的设计者Craig R. McClanahan曾经说当时他设计struts时有两个条件不成熟：当时没有测试驱动开发的概念；当时JVM的垃圾收集性能太次。假如现在重新设计的话，他也会采用每个request生成一个新对象的设计方法，这样可以解决掉线程安全的问题了。
然而仔细跟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出来，业务逻辑在大多数的情况下应该是单例的。
回头看一下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前后保持状态.
这篇非原创，但也不某个具体作者写的，是我收集的多篇资料整理而成的，版权都属于原作者
362
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
