Spring MVC framework深入分析之一--总体分析

嗯，谢谢robbin的补充，看来我对Webwork掌握得还比较初级，还要多学习。
但是还是提几点意见吧：
一、Webwork引入AutoWiringInterceptor的配置偶不熟悉，偶以前是用spring-xwork-integration的包。robbin老大能不能解释一下？

完全同意，本来业务层和Web层的两个配置文件就是分开的。我的本意是指使用spring-xwork-integration时要在Spring里配置好bean，再在xwork的配置文件里引用它，这样就不太方便了。
二、这个其实我说得很明白了，完全是个人喜好，呵呵！偶只是说spring的MVC责任比较明确，从开发的角度两个都挺方便的。
四、偶不同意用了Mock之后会很痛苦，因为Spring已帮我们实现掉这些Mock 了，我们只要往里塞东西就行了。
六、虽然我不知道webwork也可以实现MultiActionController，但正如robbin说的这其实是Webwork的一个问题，因为Action的状态问题会导致Action的每个方法责任不明确。

我觉得Spring MVC和Webwork都是很不错的MVC架构，选择哪个也是个人喜好的问题。我提的那几点看法里其实也没有包含个人倾向，比如interceptor,ModelAndView等等，所以如果你觉得webwork好的话，就继续用吧。我写这篇文章的目的不是让大家都放弃Webwork，而主要是就技术上进行分析，总结经验，并从中学到更多的东西。
但是Spring的MVC绝对是一个不错的选择，我们在去年的项目里用得很成功。

我没有具体用过Spring MVC，看了楼主的分析，感觉长进不少。目前我用的是webwork，因为我感觉webwork可以解决我的大部分困扰的问题。

我最喜欢的就是webwork强大的拦截器框架，它几乎可以完成你在Action层的大部分要求。另外就是喜欢OGNL的数据填充，让你无须再关心从页面上取数据了。

http://wiki.opensymphony.com/display/WW/WebWork+2+Spring+Integration

参见webwork的wiki最下面的ActionAutowiringInterceptor方法。采用这种方法，不需要在spring里面配置webwork的action，也不需要在webwork里面配置依赖的springbean(按名称自动注入)



我也用过spring的HttpServlet的Mock，总体感觉还是不方便，后来就干脆自己写Mock Object了，用Mock只是不得以，真的没有Webwork的ActionContext方便，差远了。



前面说过了，这取决于模型的设计。webwork的action模型要求实例action，这会带来很多编程上的好处，并且这些好处是显而易见的，不用多费口舌，做一个项目就清楚了。

对于Spring/Struts来说，action拆还是合，其实没有任何区别，因为action是无状态的，所以这个功能对MVC来说，意义并不大。

恩,看来ActionAutowiringInterceptor是个好东西，可惜学校里连https都上不了，有空下载来玩玩。不过我觉得实现起来可能也不是太难，只要从ServletContext里把ApplicationContext读出来做为parent，再加入新的child applicationContext的BeanDefinition就可以了。主要是这个点子不错，呵呵。
后两项就不跟robbin争了，我觉得纯粹是个人喜好问题。谢谢robbin

我不喜欢听没有证据的东西。不知道你指的"SPRING MVC是相当烂的一个东西"什么意思？不知道你使用SPRING MVC有多久？是做了具体的项目体会出来它很烂还是玩了半天就觉得它烂？能不能举出具体的例子？
我认为Spring MVC很棒，因为这是我在做项目和学习的过程中体会到的。
国外有很多牛人都认为Spring MVC很棒，Rod Johnson从2000年就已经在他的项目中使用了自己的MVC架构，至今有很多大型的项目都在使用这个MVC架构。Spring MVC在此之上做了很多的改进，总结了struts和Webwork（当时Rickard Oberg已经开发出版本一了）的不足，是经过很多考验和实践总结的成果，希望大家不要只花了半天时间就把它否定掉。

我觉得这个评价挺客观的,没有绝对的完美,相对而言(WW2,STRUTS)不够简单易用...

功能强大，灵活性高的东西，必定设计的会稍微复杂一点。就像傻瓜相机和专业摄影用的相机一样。

还没用过Spring，但我赞成yanchang所说。

之前我与同事一起做的一项目就在struts与hibernate里抽象了自己的一层。

为什么？

主要是因为作为工具级框架，它提供了过多的特性。而这些特性对于特定项目来说是不必要的，但这对工具级框架却特别重要。

举个例子，hibernate里使用带参数查询时，在Query里定义了十几个接口。在我的项目里，我只允许使用一种接口。另外，我们都知道hibernate使用起来较烦。如果你不对Session，SessionFactory做一下封装，实在是没法用。

也就是说对于特定项目来说，如果一个框架提供了十种方法实现一种功能，你应该让所有的成员使用同一种方式来实现这种功能。这应该是一种较好的设计选择。

1:
一般一个稍微复杂点的action大概起码要用到3，4个entity，如果不是像webwork这样通过action属性传递参数，估计你光光得到这些需要的entity就要写好多行代码了。而且如果你的action是可以执行多个请求的，那么每个执行方法比如insert(),update()当然也要从新去取这些需要的entity。如果你需要向页面传递一个以上的对象，比如我要传几个List（页面中生成下拉选择用），几个entity那估计你传递的代码也要写好多了。eg:request.setAttribute("list1",list1);
2:
我觉得配置本身是一个问题，因为配置，那么你必须将代码跟配置保持一致，比如我在代码中改个跳转的页面，代码中改完后必须同步去修改配置，而且在多个人开发的请况下，维护这个配置的版本一致也是一个问题。webwork中可以通过注释来生成，在很大程度上解决了这两个问题。使得不需要去关注配置，只需关注代码。spring mvc我就做过一个简单的例子，没在项目中用，不过我想应该达不到我上面的几个要求。
总的来说，spring过于理想化了（而且有些不足之处），在实际项目中用还是不能方便的使用。

我觉得评价一个web framework的重要方面就是是否能隐藏HttpServletRequest,HttpSession的使用。
  request，session是用来在页面之间传递变量的，不过在我们action的实际使用中需要的是已经组装好的entity对象，所以我们使用各种手段来自动组装entity对象，包括自动从页面取参数组装成entity（甚至是entity元素的一个List）和自动传递entity的属性到页面显示，而不用手动去做（eg:request.setAttribute("lista",list)）。我觉得像webwork这样的做法非常好，即隐藏了它们的使用，又可以在必须要的时候得到。