WebWork简介

最新推荐文章于 2019-09-18 15:23:42 发布

不学-何为

最新推荐文章于 2019-09-18 15:23:42 发布

阅读量999

点赞数

分类专栏： WebWork 文章标签： webwork action servlet struts freemarker velocity

本文链接：https://blog.youkuaiyun.com/xyls_2009/article/details/5738605

版权

WebWork 专栏收录该内容

1 篇文章

订阅专栏

WebWork虽然没有Struts 1那样赫赫有名，但也是出身名门，WebWork来自另外一个优秀的开源组织：opensymphony，这个优秀的开源组织同样开发了大量优秀的开源项目，如Qutarz、OSWorkFlow等。实际上，WebWork的创始人则是另一个Java领域的名人：Rickard Oberg（他就是JBoss和XDoclet的作者）。
相对于Struts 1存在的那些先天性不足而言，WebWork则更加优秀，它采用了一种更加松耦合的设计，让系统的Action不再与Servlet API耦合。使单元测试更加方便，允许系统从B/S结构向C/S结构转换。
相对于Struts 1仅支持JSP表现层技术的缺陷而言，WebWork支持更多的表现层技术，如Velocity、FreeMarker和XSLT等。
WebWork可以脱离Web应用使用，这一点似乎并没有太多优势，因为，一个应用通常开始已经确定在怎样的环境下使用。WebWork有自己的控制反转（Inversion of Control）容器，通过控制反转，可以让测试变得更简单，测试中设置实现服务接口的Mock对象完成测试，而不需要设置服务注册。
WebWork 2使用OGNL这个强大的表达式语言，可以访问值栈。OGNL对集合和索引属性的支持非常强大。
WebWork建立在XWork之上，使用ServletDispatcher作为该框架的核心控制器，处理HTTP的响应和请求。
从处理流程上来看，WebWork与Struts 1非常类似，它们的核心都由控制器组成，其中控制器都由两个部分组成：
 核心控制器ServletDispatcher，该控制器框架提供。
 业务逻辑控制器Action，该控制器由程序员提供。
相对Struts 1的Action与Servlet API紧紧耦合的弱点来说，WebWork的Action则完全与Servlet API分离，因而该Action更容易测试。
WebWork的Action可以与Servlet API分离，得益于它灵巧的设计，它使用一个拦截器链，负责将用户请求数据转发到Action，并负责将Action的处理结果转换成对用户的响应。
当用户向Web应用发送请求时，该请求经过ActionContextCleanUp、SiteMesh等过滤器过滤，由WebWork的核心控制器拦截，如果用户请求需要WebWork的业务逻辑控制器处理，该控制器则调用Action映射器，该映射器将用户请求转发到对应的业务逻辑控制器。值得注意的是，此时的业务逻辑控制器并不是开发者实现的控制器，而是WebWork创建的控制器代理。
创建控制器代理时，WebWork需要得到开发者定义的xwork.xml配置文件，控制器代理以用户实现的控制器作为目标，以拦截器链中的拦截器作为处理（Advice）。
提示 WebWork中创建控制器代理的方式，就是一种AOP（面向切面编程）编程方式，只是这种AOP中的拦截器由系统提供，因此无需用户参与。如果读者需要获取更多关于AOP编程的知识，请参阅AOP相关资料，或笔者所著的《Spring 2.0宝典》一书的第6章。
开发者自己实现的业务逻辑控制器只是WebWork业务控制器的目标——这就是为什么开发者自己实现的Action可以与Servlet API分离的原因。当开发者自己的Action处理完HTTP请求后，该结果只是一个普通字符串，该字符串将对应到指定的视图资源。
指定的试图资源经过拦截器链的处理后，生成对客户端的响应输出。