spring3mvc与struts2比较

项目刚刚换了web层框架，放弃了struts2改用spring3mvc
当初还框架的时候目的比较单纯---springmvc支持rest，小生对restful url由衷的喜欢
不用不知道 一用就发现开发效率确实比struts2高

我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置
spring3 mvc可以认为已经100%零配置了（除了配置springmvc-servlet.xml外）

比较了一下strus2与spring3 mvc的差别

============================================
struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter getter方法把request中的数据注入
struts2实际上是通过setter getter方法与request打交道的
struts2中，一个Action对象对应一个request上下文

spring3 mvc不同，spring3mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去
在spring3mvc中，一个方法对应一个request上下文

好了 我们来整理一下
struts2是类级别的拦截， 一个类对应一个request上下文，
springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应
所以说从架构本身上 spring3 mvc就容易实现restful url
而struts2的架构实现起来要费劲
因为struts2 action的一个方法可以对应一个url
而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了

===================================
spring3mvc的方法之间基本上独立的，独享request response数据
请求数据通过参数获取，处理结果通过ModelMap交回给框架
方法之间不共享变量

而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的
这不会影响程序运行，却给我们编码 读程序时带来麻烦

====================================
spring3 mvc的验证也是一个亮点，支持JSR303
处理ajax的请求更是方便 只需一个注解@ResponseBody ，然后直接返回响应文本即可

附上一段代码

	@RequestMapping(value="/whitelists")
	public String index(ModelMap map){
		Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId()) ;
		List<Group> groupList = groupManager.findAllGroup(account.getId()) ;
		map.put("account", account);
		map.put("groupList", groupList);
		return "/group/group-index" ;
	}
        //@ResponseBody ajax响应  
	@RequestMapping(value="/whitelist/{whiteListId}/del")
	@ResponseBody  
	public String delete(@PathVariable Integer whiteListId){
		whiteListManager.deleteWhiteList(whiteListId) ;
		return "success" ;
	}

评论

106 楼 slaser 2010-06-25  

downpour 写道

你的观点基本上是在胡扯。

Struts2的拦截器和OGNL使用是天然的优势，你用Spring是无法获得这两者带来的好处的。对于那些说Spring天然就支持AOP的朋友，我只能说这是完全缺乏实践的说法。因为基于SpringMVC的模式下，拦截的内容只能基于参数和返回值，这样的拦截的限制极大，与Struts2的拦截器是完全不在一个层面上的东西。

Struts2比较于SpringMVC的最大优势在于它丰富的执行层次。从ActionProxy作为入口开始，由ActionInvocation来调度Interceptor、Action、PreResultListener、Result这些元素的执行。并且Struts2提供了你在所有这些层次的元素之上进行编程的可能性。所以就扩展性而言，别的框架是无法比拟的。

Struts2在技术上对于SpringMVC是完胜的。SpringMVC能够做的，Struts2全部都能做，并且做得比SpringMVC更优雅。

SpringMVC唯一的优点在于它足够简单，一个只具有基本功能的Web层框架，我们是不能要求它干什么的。

第一，没看出来spring的aop拦截限制了什么应用了，我的输入输出都在参数和返回值上，为什么还需要其他拦截，你能拿出什么实际的例子让spring mvc做起来很难受的么？另外，说起spring aop天然支持aop有什么错,spring aop的后面是aspectj,对于领域对象的注入和拦截也是可以靠aspectJ搞定的。
第二，难道Spring MVC执行层次不多，定制化不强？可插入url的解析，多种view的支持，Spring Webflow，Security集成被你无视了。
第三，不认为Struts2在技术上完胜，struts2走了和Spring MVC不同的路，这个才是关键，而我觉得它现在是个半成品。论优雅，可以去学习JSF.

105 楼 daquan198163 2010-06-24  

13.1.2. Features of Spring Web MVC

Spring's web module provides a wealth of unique web support features, including:
    *Clear separation of roles - controller, validator, command object, form object, model object, DispatcherServlet, handler mapping, view resolver, etc. Each role can be fulfilled by a specialized object.
    *Powerful and straightforward configuration of both framework and application classes as JavaBeans, including easy referencing across contexts, such as from web controllers to business objects and validators.
    *Adaptability, non-intrusiveness. Use whatever controller subclass you need (plain, command, form, wizard, multi-action, or a custom one) for a given scenario instead of deriving from a single controller for everything.
    *Reusable business code - no need for duplication. You can use existing business objects as command or form objects instead of mirroring them in order to extend a particular framework base class.
    *Customizable binding and validation - type mismatches as application-level validation errors that keep the offending value, localized date and number binding, etc instead of String-only form objects with manual parsing and conversion to business objects.
    * Customizable handler mapping and view resolution - handler mapping and view resolution strategies range from simple URL-based configuration, to sophisticated, purpose-built resolution strategies. This is more flexible than some web MVC frameworks which mandate a particular technique.
    *Flexible model transfer - model transfer via a name/value Map supports easy integration with any view technology.
    *Customizable locale and theme resolution, support for JSPs with or without Spring tag library, support for JSTL, support for Velocity without the need for extra bridges, etc.
    *A simple yet powerful JSP tag library known as the Spring tag library that provides support for features such as data binding and themes. The custom tags allow for maximum flexibility in terms of markup code. For information on the tag library descriptor, see the appendix entitled Appendix D, spring.tld
    *A JSP form tag library, introduced in Spring 2.0, that makes writing forms in JSP pages much easier. For information on the tag library descriptor, see the appendix entitled Appendix E, spring-form.tld
    *Beans whose lifecycle is scoped to the current HTTP request or HTTP Session. This is not a specific feature of Spring MVC itself, but rather of the WebApplicationContext container(s) that Spring MVC uses. These bean scopes are described in detail in the section entitled Section 3.4.4, “The other scopes”

104 楼 daquan198163 2010-06-24  

struts2能实现wizard和webflow吗？

我觉得拦截器机制和大量的扩展点真没什么好炫耀的，够用就行了，95分和100分的区别而已。

103 楼 wen66 2010-06-24  

在借位置问一下各位开发同仁, 现在不想做java web开发了, 想转去做java的其它方面开发, 大家有没有什么好的建议. 先谢谢了.

102 楼 wen66 2010-06-24  

小声的问几下:
1.相对于struts2, spring3来说, playframework(http://www.playframework.org/)给我们带来的优势是什么, 有没有人用playframework做过项目, 在实际中给我们带来了什么好处.

2.有没有人用grails1.3(基于spring3)来做过项目, 用它来做项目是不是真的比ssh要快不少啊. 给我们带来的好处是什么?

3.有没有人用spring roo来做过项目, 通过看官方的视频来说, 它好像很不错哦. 它的web部分也是基于spring3 的mvc的. 还有spring roo的1.1.1(如果没有记错的话), 将会和gwt2进行整合(这个词可能用得不合适,应该说是包含gwt2插件吧), 包括在sts(springsource tools suit)开发工具上做大量的支持.

4. 目前springsource开发了很多的项目(如spring integer, spring ws, spring batch), 问一下大家都用到了哪些啊, 还有开发spring应用,大家用到的开发工具都是什么啊, 是不是sts啊. 关于springsource的dmserver大家有没有用过, 有研究过的能出来说说吗.

5. 关于人人网基于spring2.5.6做的web框架 [paodingRose]http://code.google.com/p/paoding-rose/, 从上面的介绍来说真的很不错. 大家能不能站出来, 发表个看法.
paoding, paoding, 又见paoding, 上次见到paoding是它的中文分词.

最近感到迷茫, 出来有几年了, 好像自己更加的什么都不明白. 不知道以后要怎么办.感觉做java web开发好痛苦, 没有ror来得方便(当然我只是对着书上的例子小试一下).既然ror做web开发那么方便, 怎么还有这么多的人还在用java来做. 做web的理想效果就是改了代码后, 刷新一下浏览器, 看效果吧, 让那些要重启服务器的概念见鬼去吧.

做java开发, 投资于spring是不是真的值啊. 现在担心以后能做什么. 哎!!
以上说得比较乱, 大家应该可以感觉到我烦躁的心了吧.

101 楼 downpour 2010-06-24  

slaser 写道

不得不说struts2的流行很大程度上沾了struts1的光。
如果还是叫webwork,我想就没有今天的争论了。
说点个人意见，
spring mvc3从架构上更像struts1继任者.(单实例，无状态)
spring mvc3基本将struts1 样式的mvc发挥到了极致（通过annotation 配置path到方法，配置验证，配置多种返回方式，无缝集成spring）.
就struts2来说，对spring mvc的优势，比如intercepter， ognl之类,是不存在的。
正真的优势或者说区别还在于多实例，用实例变量扮演model.
用实例变量的好处是action可以是有状态的，可惜的是，struts2还没有提供action实例在不同request之间的重用。
说明白点，就是struts2的action多实例却无状态，也没有scope, 这样基本丧失model作为实例变量的最大优势。
struts2目前优势就是：
1.线程安全.（这是个伪优势，没人在struts1或者spring mvc里面用实例变量接受参数）
2.可读性。-这点我承认，如果你action分的很细，一眼就知道model是什么东西了。spring mvc这点还是相当扭捏的，我要到方法体里面去找。可就这点优势，如果你用大action, 实例变量一多，我又糊涂了，那个实例变量用在那个方法里面？
综上所述，struts2技术上对spring mvc3确实基本完败。

struts2的出路不是没有。那就是把struts2的action改造成为JSF的BackedBean, 提供session, request, application甚至conversation作用域，同时废弃JSF的客户端组件。

你的观点基本上是在胡扯。

Struts2的拦截器和OGNL使用是天然的优势，你用Spring是无法获得这两者带来的好处的。对于那些说Spring天然就支持AOP的朋友，我只能说这是完全缺乏实践的说法。因为基于SpringMVC的模式下，拦截的内容只能基于参数和返回值，这样的拦截的限制极大，与Struts2的拦截器是完全不在一个层面上的东西。

Struts2比较于SpringMVC的最大优势在于它丰富的执行层次。从ActionProxy作为入口开始，由ActionInvocation来调度Interceptor、Action、PreResultListener、Result这些元素的执行。并且Struts2提供了你在所有这些层次的元素之上进行编程的可能性。所以就扩展性而言，别的框架是无法比拟的。

Struts2在技术上对于SpringMVC是完胜的。SpringMVC能够做的，Struts2全部都能做，并且做得比SpringMVC更优雅。

SpringMVC唯一的优点在于它足够简单，一个只具有基本功能的Web层框架，我们是不能要求它干什么的。

100 楼 slaser 2010-06-24  

xly_971223 写道

icewubin 写道

byk 写道

curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。
所有从开发效率和维护效率上考虑。
我支持curd操作 集中在一个 action。
把curd分成4个action绝对会导致开发人员的反抗。

你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。

维护和修改成本一般远大于开发成本。

即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。

靠谱
所以说赶紧扔了struts2吧
springmvc3从根子上帮助了开发人员

不得不说struts2的流行很大程度上沾了struts1的光。
如果还是叫webwork,我想就没有今天的争论了。
说点个人意见，
spring mvc3从架构上更像struts1继任者.(单实例，无状态)
spring mvc3基本将struts1 样式的mvc发挥到了极致（通过annotation 配置path到方法，配置验证，配置多种返回方式，无缝集成spring）.
就struts2来说，对spring mvc的优势，比如intercepter， ognl之类,是不存在的。
正真的优势或者说区别还在于多实例，用实例变量扮演model.
用实例变量的好处是action可以是有状态的，可惜的是，struts2还没有提供action实例在不同request之间的重用。
说明白点，就是struts2的action多实例却无状态，也没有scope, 这样基本丧失model作为实例变量的最大优势。
struts2目前优势就是：
1.线程安全.（这是个伪优势，没人在struts1或者spring mvc里面用实例变量接受参数）
2.可读性。-这点我承认，如果你action分的很细，一眼就知道model是什么东西了。spring mvc这点还是相当扭捏的，我要到方法体里面去找。可就这点优势，如果你用大action, 实例变量一多，我又糊涂了，那个实例变量用在那个方法里面？
综上所述，struts2技术上对spring mvc3确实基本完败。

struts2的出路不是没有。那就是把struts2的action改造成为JSF的BackedBean, 提供session, request, application甚至conversation作用域，同时废弃JSF的客户端组件。

99 楼 slaser 2010-06-24  

superyang 写道

xly_971223 写道

superyang 写道

在web层只关心的就是上传文件功能...
现在做网站或系统全部静态化.....
开发效率120%


网站大了，什么代码都有。。整个网站的代码都乱七八糟的。

网站大了就要做项目切分了
大项目切成多个项目
不会这么乱

有此人不会写代码的,不管代码的质量怎样,只要实现功能就OK,最后网站变得慢,那时想提高网站性能也就很难了...
ps:这几天,网站变慢了,什么方案都弄,我是怕了...

这是你们招聘的时候，人员能力参差不齐的原因。
关键位置在人力上花钱是不会浪费的。

98 楼 superyang 2010-06-24  

xly_971223 写道

superyang 写道

在web层只关心的就是上传文件功能...
现在做网站或系统全部静态化.....
开发效率120%


网站大了，什么代码都有。。整个网站的代码都乱七八糟的。

网站大了就要做项目切分了
大项目切成多个项目
不会这么乱

有此人不会写代码的,不管代码的质量怎样,只要实现功能就OK,最后网站变得慢,那时想提高网站性能也就很难了...
ps:这几天,网站变慢了,什么方案都弄,我是怕了...

97 楼 xly_971223 2010-06-24  

superyang 写道

在web层只关心的就是上传文件功能...
现在做网站或系统全部静态化.....
开发效率120%


网站大了，什么代码都有。。整个网站的代码都乱七八糟的。

网站大了就要做项目切分了
大项目切成多个项目
不会这么乱

96 楼 superyang 2010-06-24  

在web层只关心的就是上传文件功能...
现在做网站或系统全部静态化.....
开发效率120%


网站大了，什么代码都有。。整个网站的代码都乱七八糟的。

95 楼 icewubin 2010-06-24  

xly_971223 写道

icewubin 写道

byk 写道

curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。
所有从开发效率和维护效率上考虑。
我支持curd操作 集中在一个 action。
把curd分成4个action绝对会导致开发人员的反抗。

你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。

维护和修改成本一般远大于开发成本。

即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。

靠谱
所以说赶紧扔了struts2吧
springmvc3从根子上帮助了开发人员

没发现“根子上”啊，个人认为两个框架都可以用，struts2还更普及一点，了解的人更多一点，加一点规范即可，并不存在哪一个框架有压倒性的优势。

在页面逻辑复杂，表单参数繁多的时候，默认就是多例的Struts2也是很好用的。

题外话：页面逻辑复杂可以通过交互方式调整（适当的地方用ajax），能简化Action这一层的代码，当然前端会增加一些JS代码。

94 楼 xly_971223 2010-06-24  

icewubin 写道

byk 写道

curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。
所有从开发效率和维护效率上考虑。
我支持curd操作 集中在一个 action。
把curd分成4个action绝对会导致开发人员的反抗。

你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。

维护和修改成本一般远大于开发成本。

即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。

靠谱
所以说赶紧扔了struts2吧
springmvc3从根子上帮助了开发人员

93 楼 icewubin 2010-06-24  

byk 写道

curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。
所有从开发效率和维护效率上考虑。
我支持curd操作 集中在一个 action。
把curd分成4个action绝对会导致开发人员的反抗。

你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。

维护和修改成本一般远大于开发成本。

即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。

92 楼 byk 2010-06-24  

curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。
所有从开发效率和维护效率上考虑。
我支持curd操作 集中在一个 action。
把curd分成4个action绝对会导致开发人员的反抗。

91 楼 slaser 2010-06-24  

downpour 写道

slaser 写道

downpour 写道

有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。

比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。

无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。

感觉这样划分并不易把握。我觉得一个页面一个action是最好操作的，虽然可能会形成一些冗余，但是可维护性很好。

你的感觉应该不准确。

举例来说，save和update的Action在多数情况下是分页面但是同Action的。

你这个例子确实使用相同action比较好，但是也不是绝对的，如果update和create有比较多不同的逻辑，是可以分2个action的。反过来如果完全差不多，为何不用一个页面？

90 楼 downpour 2010-06-23  

slaser 写道

downpour 写道

有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。

比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。

无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。

感觉这样划分并不易把握。我觉得一个页面一个action是最好操作的，虽然可能会形成一些冗余，但是可维护性很好。

你的感觉应该不准确。

举例来说，save和update的Action在多数情况下是分页面但是同Action的。

89 楼 slaser 2010-06-23  

downpour 写道

有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。

比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。

无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。

感觉这样划分并不易把握。我觉得一个页面一个action是最好操作的，虽然可能会形成一些冗余，但是可维护性很好。

88 楼 downpour 2010-06-23  

有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。

比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。

无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。

87 楼 icewubin 2010-06-23  

框架是死的，人是活的。

如果对Struts默认的获取参数的方式不是很感冒，完全可以利用现成的很多工具方法，自己获取参数，尤其是一些非表单的参数，这样就不需要那么多set方法，可以一定程度的减少楼上说的第二种情况中的冲突。

还有页面和功能的划分也可以灵活一点的，因为还有些项目中还有很多Ajax请求呢。