论坛首页 Java企业应用论坛

请教:struts和webwork2的比较

浏览 6163 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2004-03-03  
转自:http://acai.ejb.cn/blog/2003_11_09_archive.html

谁比较了解webwork2?我想了解一下struts有什么比webwork胜出的地方,
从下文来看似乎都是不如webwork2,前一段时间出于各种考虑,最后选择了struts作为应用框架。


引用
比较内容
Struts
WebWork2

Action 类
在Struts里面,每一个
Action Class都需要扩展org.apache.struts.action.Action;这个在Java编程中会引来一些问题,就是关于多种继承的问题
Webwork仅仅需要implement com.opensymphony.xwork.Action Interface,您也可以implement其它的interface来实现更多的功能,譬如:validate(验证),localware(国际化)等,当然 webwork2也提供了一个类ActionSupport 集成了以上功能。Developer可以根据需要实现不同的功能。

线程模型
Struts Actions必须是thread-safe方式,它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必须统一同步,这个就引起了线程安全的问题。
Webwork 2 actions每一个请求对应一个action,因此没有线程的安全问题。实际上Servlet 容器对应每一个请求会产生许多Object,这种一个请求产生许多object的例子没有证明对性能产生太多的影响。现在Web容器都是这么处理Servlet的。

Servlet的依赖
Struts处理一个Action时候必须要依赖ServletRequest and ServletResponse。所以这一层摆脱不了Server容器。而serveltRequest可能会被web层的Context使用。
Webwork2 每一个action不依赖任何层和任何容器。他们使用Request和response是通过ActionContext,所以这个对于逻辑层的分离是很重要的。

测试
因为Struts的每一个action都必须用到request和response所以都必须通过web层来进行测试。这就导致了许多测试struts都要通过web容器(尽管现在有许多测试方法cactus mock 等)。
Webwork的action能够通过赋予一定的属性。就可以执行。同时您可以使用一个mock的实例去测试,而不是通过启动web容器来进行测试。

FormBean
Struts 需要一个FormBeans针对每一个Form。而使用DynaBeans实际上没有太大的意义。不能够很好的处理现有的模型。
Webwork 能够动态的收集web的数据然后在赋值给bean。同时它还能够使用FormBean模式。Webwork2还允许现有的ModelDrvien进行导入处理。能够处理它就像处理action自己的属性一样。

前端表达语言
Struts大部分使用的是JSTL EL(JSP2。0)去获得数据的。在Collection上面处理显得很弱。
Webwork前端可以使用JSTL同时也可以使用多种表现形式。譬如:velocity freemaker jspparer xml等等。Webwork2 利用ongl建立一个valuestack来搜集数据

类型的转换
Struts FormBeans把所有的数据都作为string类型。得到一个自己需要的类型然后展示给用户是很困难的。
Webwork2 数据都是转换成Java中的类型。这个根据Form的类型自动转换。然后操作这些bean十分方便。

对Action 执行前和后的处理
Struts处理action的时候是基于class的hierarchies,很难在action处理前和后进行操作。
Webwork2 允许您处理action可以通过interceptor,就是在每一个action处理前或者后进行其它操作。

验证处理
因为struts的FormBean的属性都被认为是string类型。许多类型的验证都要进行类型转换的处理。FormBean对一个验证链的处理显然不行。
而webwork2的验证采用的是interceptor设计模式。它的这种验证方式决定了它十分灵活。而且一个验证可以重复不断的使用仅仅需要一个XML文件的定义。实际上webwork2的验证是采用了xwork的验证框架。

Action的链的控制
Struts里面每一个action对应一个处理,如果一个action转向另外一个action就很困难了。
Webwork使用一个强大的DispatcherChain去处理这个action链。很方便的从一个处理到另外一个处理。
   发表时间:2004-03-04  
引用
出于各种考虑,最后选择了struts作为应用框架
,那是出于什么考虑,选定了struts的呢???
0 请登录后投票
   发表时间:2004-03-04  
用的人多,技术风险小。
做了两个demo,还算是可以。

目前觉得struts没有提高开发效率,反而降低了。
就算是是熟练了,估计也不会太高。期望依靠他应该还算是良好的结构,维护起来比较简单。

可重用的构件不多,也不太易用。
我昨天看了www.bstek.com,觉得很不错,但是不免费。做web开发,bstek提供了完整的方案。我稍微了解了一下,感觉起码对开发速度会有明显的提高。
0 请登录后投票
   发表时间:2004-03-04  
也一度打算用tapestry,但是最大的风险是,技术资料太少,万一搞不定,太耽误时间。
0 请登录后投票
   发表时间:2004-03-08  
可以自己写一些代码生成工具,提高开发效率
0 请登录后投票
   发表时间:2004-03-09  
我对楼上的话有些疑问,楼上所
引用
这种一个请求产生许多object的例子没有证明对性能产生太多的影响。现在Web容器都是这么处理Servlet的。
,web容器对同一servlet会产生多个实例么???怎么可能!
   另外action的同步是在Servlet中间保证了,不需要去考虑什么资源的同步性了,再说了,多个实例访问同一个资源,难道没有同步问题??那样更严重的。所以线程安全的问题在action这一块是根本不需要去考虑的,也不会有问题的。
   不过话说回来,其他的,像你所所的,这个webwork2还真是不错,也谢谢楼上指点。
0 请登录后投票
   发表时间:2004-03-09  
唔.......servlet应该实例只有一个吧.......
0 请登录后投票
   发表时间:2004-03-15  
我们很久以前自己开发过一个template的,没有form,action什么的概念,只是为了分离html和jsp页面,每个要显示的html页面对应jsp页面,通过jsp来处理逻辑和数据的输出,在html上通过自己定义的标签来替换.其实也就是把html读入到对应的jsp中,只不过这样对于开发效率能提高,页面制作人员能够完全打开html页面来做页面.不会和程序人员有影响!
0 请登录后投票
   发表时间:2004-03-17  
从技术层面来讲,WW相比于Struts,有太多的优势,楼上所讲述的是一些"大"的方面,我结合我在项目中的实际体验,谈一下WW的一些细节方面的优点:

1.WW给程序员更大的灵活性,也就是做一件事可以有多种方法,一般人可能认为灵活性是一个很虚的比较因素,有人可能会说,我根本不需要其太多种方法,我只需一种就行了,但不要忘记一百个程序员就有一百零一种个性,每个人都想以自己的方式做事,是但作为一个通用的WEB框架,想得到大多数程序员的认可,想适应众多的软件项目,灵活性是非常重要的.扯远了,具体说:

1.1.WW支持多种表示层技术如JSP,Velocity,xslt,等.而且增加一种表示方式也很简单,只需实现一个Result接口就行.我在项目中就实现了一个供用户下载或打开WORD文件的WordResult;

1.2.WW支持Action的多种定义方式,在Struts中一个页面URL(如:user.create.action)就会对应一个Aciton类(一般是UserCreateAction),相应地,user.delete.action又会对应一个UserDeleteAction类,这样会导致众多的小类,当然这也并不是什么坏事,但WW除了支持Struts中的这种定义Action的方式外,还支持多个action映射到同一个Action类.

1.3.WW的ACTION类可以实现其Action接口,也可以不实现任何接口,只须有一个public String XXX()形式的方法即可, 而Struts中的Action实现必须从Struts的Action类派生. 正因为其实现Action的灵性,才有了映射多个action到一个ACtion类的基础.

1.4.WW支持action的包的概念,也就是action的名称空间,如user/create.action就对应到user包中的create.在Struts1.1中好象支持多个Model,这一点与WW的包有点相似,我未用过Struts的这一功能,不好比较,但个人感觉还是不同至少在灵活性方面.

1.5.WW的Action定义文件支持<include>元素,也就是可以定义多个映射文件,然后用include将它们组织到一起. 这一点对于组织管理映射文件非常有好处. 同样Struts1.1中的model也支持多个映射文件,个人感觉灵活性上比不上WW. 另外现在WW只支持一个包一个定义文件,不能支持一个包在多个映射文件中定义,因为后面定义的包会覆盖前面的定义,但通过扩展一个config类,很容易修改WW的这一形为,而且相信以后的版本应该会对此作出修改.

1.6.理论上WW支持多种形式的客户端,WEB客户端是最常用的,但其action对javax.servlet包没有任何依赖,所以这些action类应该完全可以用于swing的客户端,不过这一点未经项目验证.

2.WW具有非常好的扩展性. 我在项目中将WW与Spring结合,只写了两个适配器类一个用于初始化的Servlet. 当然这并不能表明其相对于Struts的优势,Struts也可与Spring结合,不过能做到如此也不简单.

3.WW比Struts更"新",WW用到了一些我认为是"新"的技术,最显著的是inspector(Struts应该没有),Ioc,而我从2002年开始接触Struts,到现在感觉Struts几乎没有太多的变化(也许是我不太了解).

4.唯一的缺憾是WW2少了Reckard Oberg的参与,而且文档太少. 我当初学WW就是冲着Reckard Oberg的名号去的, 可等我看完WW1.4的源码和文档才知道有一个WW2, 因WW1.4不在升级,所以我的项目只好使用WW2.
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics