首页 > 代码库 > DelegatingActionProxy
DelegatingActionProxy
使用 DelegatingActionProxy
使用 DelegatingRequestProcesso 非常简单方便,但有一个缺点:RequestProcessor 是Struts 的一个扩展点,也许应用程序本身就需要扩展RequestProcessor ,而DelegatingRequest Processor 已经使用了这个扩展点。
为了重新利用 Struts 的 RequestProcessor 这个扩展点,有以下两个方法:使应用程序的 RequestProcessor 不再继承 Struts 的 RequestProcessor ,改为继承DelegatingRequestProcessor 。
使用 DelegatingActionProxy。
前者常常有一些未知的风险,而后者是 Spring 推荐的整合策略。使用 DelegatingActionProxy 与DelegatingRequestProcessor 的目的只有一个,都是将请求转发给 Spring管理的 bean。
DelegatingRequestProcessor 可直接替换了原有的 RequestProcessor,并在请求转发给action 之前,转发给 Spring 管理的 bean; 而 DelegatingActionProxy 则被配置成 Struts 的action,即所有的请求先被 ActionServlet拦截,然后将请求转发到对应的 action,而 action的实现类全都是 DelegatingActionProxy; 最后由 DelegatingActionProxy 将请求转发给Spring 容器的 bean。
可以看出:使用 DelegatingActionProxy 比使用 DelegatingRequestProcessor 要晚一步转发到 Spring 的 contexto 但通过这种方式可以避免占用扩展点。与使用 DelegatingRequestProcessor 对比,使用 DelegatingActionProxy 仅需要去掉controller 配置元素,并将所有的 action 实现类改为 DelegatingActionProxy 即可。其详细的配置文件如:
<!--XML 文件版本,编码集--> |
DelegatingActionProxy 接受 ActionServlet 转发过来的请求,然后转发给ApplicationContext管理的bean,这是典型的链式处理。
通过配置文件可看出,在struts-config.xml文件中配置了大量DelegatingActionProxy实例, Spring 容器中也配置了同名的Action。即 Struts 的业务控制器分成了两个部分:
第一个部分是Spring 的 DelegatingActionProxy,这个部分没有实际意义,仅仅完成转发:
第二个部分是用户的Action实现类,负责实际的处理工作。
这种策略的性能比前一种的策略要差一些,因为需要多创建一个DelegatingActionProxy实例。而且在J2EE应用中的Action非常多,这将导致需要大量创建DelegatingActionProxy实例,在使用一次之后,要等待垃圾回收机制回收,从而降低了其性能。
DelegatingActionProxy 的执行效果如图7.6所示。
图 7.6 DelegatingActionProxy 整合策略登录成功的效果 |