艰难的抉择：SpringMVC OR Struts2
目前公司在选择MVC框架时，出现了分歧：
一派支持SpringMVC，理由是足够强大，已经在两个项目成功使用
另一派主张用Struts2.0，理由是觉得它比SpringMVC强大，对AJAX集成的好
我是属于第一派的，但是由于我不熟悉Struts2.0（webwork2），所以也不能说服另一派的
下面列出我对这两个都很优秀的框架的评估，请各位帮忙评判一下：
------------------------SpringMVC-----Struts2.0（webwork2）--------------获胜者
开发效率----------------5-------------？---------------------------------？
运行效率----------------5-------------4（action非单例）------------------SpringMVC
学习成本----------------4-------------3（同事反应学习曲线比较陡）--------SpringMVC
与Spring集成------------5（无缝集成） 4----------------------------------SpringMVC
难易程度
validator集成-----------4（commons）--5----------------------------------Struts2.0
AJAX集成----------------4-------------5（丰富的tag支持）-----------------Struts2.0
可测试性----------------5-------------5----------------------------------平局
91 楼 zhuxinyu 2008-05-06 现在差不多学习完了struts2 感觉是挺强大的，不过对dojo的集成 让人吃不消，速度太慢，对于jfreechar的集成有太僵硬。
不知道struts2的下个版本会有什么好的提升。springmvc 玩过不过太让人难受，新版本是提升了不少，有待比较。
92 楼 laiseeme 2008-05-06 jfreechart和struts的集成怎么讲? 93 楼 laiseeme 2008-05-07 下载了新的jsonlib依赖了好多jar包,还有个xom那个始终下载不了... 94 楼 senbao18 2008-05-07 实践,时间,证明一切~~~ 95 楼 store88 2008-05-08 tedeyang 写道推荐Spring MVC，尤其是2.5版本。
struts2.0确实没真正在产品里用过，不过两年前我也面临这样的技术选型。当时比较专制，就用spring mvc，因为我认为struts的强项在于表示层——确切地说是tag，而我最讨厌tag！采用spring mvc可以沿袭spring的IOC、AOP思想，对具备spring根基的人来说，开发学习是统一的，而且非常易于扩展。
呵呵，两年来只需要用到最简单的controller接口，简单到底！清清爽爽！
天杀的都知道struts的主要部分是作为controller component存在的
view只是附带的功能而已 96 楼 icewubin 2008-05-08 laiseeme 写道下载了新的jsonlib依赖了好多jar包,还有个xom那个始终下载不了...
我用的是json-lib-2.0-jdk13.jar，没见过要用xom啊。 97 楼 bloodwolf_china 2008-05-08 我推荐使用struts2 MVC,Spring的mvc对于同一控制器处理不同来源的请求并渲染不同View相当麻烦。相反struts2对于Controller和View的处理相当灵活。 98 楼 daquan198163 2008-05-08 再加两条springmvc的优点：
1、验证框架支持验证器链，可以加入纯服务器端验证（比如验证id、email重复），扩展性极强，原有的web端验证器不受影响，页面错误显示也不需做任何改动
参考org.springframework.validation.Validator接口
2、透明远程调用，如xfire、hessian等，都可以通过一个controller发布，非常的简洁、一致
参考org.springframework.remoting.caucho.HessianServiceExporter 99 楼 jianfeng008cn 2008-05-17 你发现的springMVC的优点，你也可以在webwork中研究下怎么实现 demo里一般也有 至于分析 robbin等人已经分析给你听了 也说了自己的意见 你怎么还是怎么真固执 假虚心呢？ 100 楼 daquan198163 2008-05-17 jianfeng008cn 写道你发现的springMVC的优点，你也可以在webwork中研究下怎么实现 demo里一般也有 至于分析 robbin等人已经分析给你听了 也说了自己的意见 你怎么还是怎么真固执 假虚心呢？
大家都是做技术的，别净说些没用的，
上面两条webwork里没有
你要是知道就说点实际的，不知道就……………… 101 楼 neptune 2008-05-18 看看spring2.5中的新mvc sample，非常好,一个控制器类基于源注释可以处理多个不同的请求。而且对submit提交处理的也非常好。我现在就在用，确定简单了很多. 102 楼 jianfeng008cn 2008-05-19 daquan198163 写道再加两条springmvc的优点：
1、验证框架支持验证器链，可以加入纯服务器端验证（比如验证id、email重复），扩展性极强，原有的web端验证器不受影响，页面错误显示也不需做任何改动
参考org.springframework.validation.Validator接口
2、透明远程调用，如xfire、hessian等，都可以通过一个controller发布，非常的简洁、一致
参考org.springframework.remoting.caucho.HessianServiceExporter
验证框架和远程调用 webwork里怎么会没有？远程调用是也不是spring MVC的 至于验证服务器和客户端的组合有很多种 webwork和springMVC 实现的区别也不大 webwork封装了多种选择而已 说设么服务端验证影响客户端验证 感觉说得有点莫名其妙 webwork的demo里真的有 你4了吗？不实践下光讨论也没啥意思吧 很多人也说了springmvc 很简单 但是用着你会发现还不如直接用webwork（当然如果你的应用很简单可能也发现不了），这样说吧 你光用servlet灵活性更好（springMVC 、webwork不就是在这上面做扩展吗，你愿意你也可以？），上面也有人很诚恳得跟你说了（“用springMVC 到最后发现为什么不直接用webwork呢”）。这个帖子为什么要这么说你呢，你难道没发现你没带着和别人讨论的心态来开贴。 103 楼 daquan198163 2008-05-19 jianfeng008cn 写道daquan198163 写道再加两条springmvc的优点：
1、验证框架支持验证器链，可以加入纯服务器端验证（比如验证id、email重复），扩展性极强，原有的web端验证器不受影响，页面错误显示也不需做任何改动
参考org.springframework.validation.Validator接口
2、透明远程调用，如xfire、hessian等，都可以通过一个controller发布，非常的简洁、一致
参考org.springframework.remoting.caucho.HessianServiceExporter
验证框架和远程调用 webwork里怎么会没有？远程调用是也不是spring MVC的 至于验证服务器和客户端的组合有很多种 webwork和springMVC 实现的区别也不大 webwork封装了多种选择而已 说设么服务端验证影响客户端验证 感觉说得有点莫名其妙 webwork的demo里真的有 你4了吗？不实践下光讨论也没啥意思吧 很多人也说了springmvc 很简单 但是用着你会发现还不如直接用webwork（当然如果你的应用很简单可能也发现不了），这样说吧 你光用servlet灵活性更好（springMVC 、webwork不就是在这上面做扩展吗，你愿意你也可以？），上面也有人很诚恳得跟你说了（“用springMVC 到最后发现为什么不直接用webwork呢”）。这个帖子为什么要这么说你呢，你难道没发现你没带着和别人讨论的心态来开贴。
少在那里断章取义，看清楚了再说
确实没打算跟你这种半瓶水的讨论 104 楼 icewubin 2008-05-19 daquan198163 写道jianfeng008cn 写道daquan198163 写道再加两条springmvc的优点：
1、验证框架支持验证器链，可以加入纯服务器端验证（比如验证id、email重复），扩展性极强，原有的web端验证器不受影响，页面错误显示也不需做任何改动
参考org.springframework.validation.Validator接口
2、透明远程调用，如xfire、hessian等，都可以通过一个controller发布，非常的简洁、一致
参考org.springframework.remoting.caucho.HessianServiceExporter
验证框架和远程调用 webwork里怎么会没有？远程调用是也不是spring MVC的 至于验证服务器和客户端的组合有很多种 webwork和springMVC 实现的区别也不大 webwork封装了多种选择而已 说设么服务端验证影响客户端验证 感觉说得有点莫名其妙 webwork的demo里真的有 你4了吗？不实践下光讨论也没啥意思吧 很多人也说了springmvc 很简单 但是用着你会发现还不如直接用webwork（当然如果你的应用很简单可能也发现不了），这样说吧 你光用servlet灵活性更好（springMVC 、webwork不就是在这上面做扩展吗，你愿意你也可以？），上面也有人很诚恳得跟你说了（“用springMVC 到最后发现为什么不直接用webwork呢”）。这个帖子为什么要这么说你呢，你难道没发现你没带着和别人讨论的心态来开贴。
少在那里断章取义，看清楚了再说
确实没打算跟你这种半瓶水的讨论
“验证id、email重复”，hibernate也有类似机制（好像叫自然键，不过我觉的，自己实现一个也很简单啊，因为总有些业务检查时要做的，就顺带一起做掉好了），而且这类机制属于业务范畴，基于判断逻辑复用的原则，这类逻辑不应放在MVC层做吧。
远程调用不是很清楚，从View的机制来看，照着SpringMVC自己写一个类似的封装也很快的，毕竟最终实现的是hessian不是SpringMVC，拿来主义嘛。我的意思是，这个功能对于选型的“权重”不够高。 105 楼 daquan198163 2008-05-19 icewubin 写道“验证id、email重复”，hibernate也有类似机制（好像叫自然键，不过我觉的，自己实现一个也很简单啊，因为总有些业务检查时要做的，就顺带一起做掉好了），而且这类机制属于业务范畴，基于判断逻辑复用的原则，这类逻辑不应放在MVC层做吧。
远程调用不是很清楚，从View的机制来看，照着SpringMVC自己写一个类似的封装也很快的，毕竟最终实现的是hessian不是SpringMVC，拿来主义嘛。我的意思是，这个功能对于选型的“权重”不够高。
验证id、email重复只是两个例子，我的意思是，对于类似的需要并且只能在后台验证的情况，SpringMVC可以处理的很优雅——与客户端验证无缝集成
远程调用本身当然不是spring做的，和validator一样，再一次的，SpringMVC让它变得更简洁、优雅
照着它的实现自己写一个当然也可以，但我现在是在比较两种框架 106 楼 jianfeng008cn 2008-05-19 daquan198163 写道icewubin 写道“验证id、email重复”，hibernate也有类似机制（好像叫自然键，不过我觉的，自己实现一个也很简单啊，因为总有些业务检查时要做的，就顺带一起做掉好了），而且这类机制属于业务范畴，基于判断逻辑复用的原则，这类逻辑不应放在MVC层做吧。
远程调用不是很清楚，从View的机制来看，照着SpringMVC自己写一个类似的封装也很快的，毕竟最终实现的是hessian不是SpringMVC，拿来主义嘛。我的意思是，这个功能对于选型的“权重”不够高。
验证id、email重复只是两个例子，我的意思是，对于类似的需要并且只能在后台验证的情况，SpringMVC可以处理的很优雅——与客户端验证无缝集成
远程调用本身当然不是spring做的，和validator一样，再一次的，SpringMVC让它变得更简洁、优雅
照着它的实现自己写一个当然也可以，但我现在是在比较两种框架
人家把Hibernate拿来说事，你还回得像模像样，你的水的确够满，我怎么断章取义了，说的就是这2个方面的，谁说webwork没有服务器端验证链的支持啊？远程服务透明发布我也说了不关springMVC的事。 107 楼 daquan198163 2008-05-19 “人家把Hibernate拿来说事，你还回得像模像样”
什么意思？
“谁说webwork没有服务器端验证链的支持啊？”
举出例子来
“远程服务透明发布我也说了不关springMVC的事”
去看看HessianServiceExporter的实现 108 楼 昏暗学子 2008-07-30 可以看看SpringMVC step by step 真是太简单了......struts2的那些tag折腾了好久 呵呵 技术不精 技术不精 109 楼 slaser 2008-07-30 springMVC和struts2我都用过。springMVC最近进化很快，挑战struts的情况也越来越明显，2.5版用起来真的很爽，我更看好springMVC。 110 楼 daquan198163 2008-11-13 Rod Johnson 写道We are putting more and more development effort behind the Spring Web Flow and Spring MVC web technologies. That investment is making them better and better for developers who chose to program in Java—and will also make them a better and better underpinning to Grails.
虽然不感到意外，但看到这段话还是令我很兴奋半天，可以断言，当初选择SpringMVC是明智的！
引自：
More Weapons for the War on Complexity: SpringSource Acquires Groovy/Grails Leader
