Spring MVC PK Struts2
我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置。spring3 mvc可以认为已经100%零配置了（除了配置spring mvc-servlet.xml外）。
Spring MVC和Struts2的区别：
1. 机制：spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。
2. 性能：spring会稍微比struts快。spring mvc是基于方法的设计，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，但要小心把握像在servlet控制数据一样。spring3 mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去，在spring3 mvc中，一个方法对应一个request上下文。而struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter getter方法把request中的数据注入；struts2实际上是通过setter getter方法与request打交道的；struts2中，一个Action对象对应一个request上下文。
3. 参数传递：struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4. 设计思想上：struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
5. intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
6. 另外，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响应，处理Ajax请求也很方便
@RequestMapping(value="/whitelist/{whiteListId}/del")
@ResponseBody
public String delete(@PathVariable Integer whiteListId) {
whiteListManager.deleteWhiteList(whiteListId);
return "success";
}
测试环境：
CPU
：酷睿
2
T5750
，内存：
DDR2-667
2G
，
Web
容器：
Tomcat6.0
，最大线程数设
置为
1000
，操作系统：
WinXP-sp3
测试步骤：
搭建
6
个
Web
工程，如下：
1.
纯
JSP:
不包含任何
MVC
框架，只有一个测试用的
JSP
页面。
2.struts1
：
包含一个
Action
，不做任何逻辑处理，直接转发到一个
JSP
页面
3.struts2 JSP
：
不包含
Action
，只包含测试
JSP
页面，直接访问该页面。
4.struts2
单例
Action
：
采用
Spring
来管理
Struts2
的
Action
实例，并配置成单例模式。
5.struts2
多例
Action
：
采用
Spring
来管理
Struts2
的
Action
实例，并配置成单例模式。
6.SpringMVC3
：
采用
Spring
来管理
Controller
实例，包含一个
Controller
，不做逻辑处
理，收到请求后，直接返回到一个
JSP
页面。
测试结果：
测试工程
请求
数
并发数
总时
间
(s)
总时
间
(s)
总时
间
(s)
平均
值
(s)
Requests Per
Second(
每秒处
理请求数
)
JSP
2000
200
5.55
3.59
4.11
4.42
452.83
struts1
2000
200
6.77
3.83
7.00
5.86
341.03
struts2 JSP
2000
200
25.20 26.30 24.11
25.20
79.35
struts2
单例
Action
2000
200
28.36 27.59 27.69
27.88
71.74
struts2
多例
Action
2000
200
31.31 31.97 39.56
34.28
58.34
SpringMVC3
2000
200
7.16
7.50
4.27
6.31
317.09
说明：
以上测试虽不是非常的精确，但基本能说明一定的问题。每个
JSP
页面和
Action
都
不包含任何的业务逻辑代码，
只是请求转发。
每轮测试取三次总时间的平均值。
所有工程的
测试均全部完成并正常处理请求，没有请求拒绝情况发生。
结论：
1.
纯
JSP
的性能应该最高，这不难理解，
JSP
被编译成
Servlet
后，没有任何多余的功能，
收到请求后直接处理。
（
这也验证一句经典的话：越原始效率就越高。
）
2.struts1
的性能是仅次于纯
JSP
的，由于
struts1
采用单例
Action
模式，且本身的封装
相比
struts2
应该说简单很多，虽然开发效率不如
struts2
，但已经过多年的实践考验，性
能稳定高效。
3.
相比来说
struts2
的性能就比较差了，这不难理解，
struts2
之所以开发方便，是由于采
用值栈、
OGNL
表达式、拦截器等技术对请求参数的映射和返回结果进行了处理，另外还采
用大量的标签库等，
这些都无疑增加了处理的时间。
因此降低了效率。
在我们实际的项目中，
我测试本地工程访问每秒处理请求数只能达到
35
左右，应该说还有不少可优化的空间。
4.
很多人认为
struts2
性能差是因为它的多例
Action
模式导致的，
但我们采用
spring
管理
struts2
的
Action
，并设置按单例方式生成
Action
实例后，发现其性能有所提高，但并不
是很明显。
由此可见，
多例
Action
模式并不是
struts2
性能瓶颈所在。
另外，
我们在
struts2
中采用
JSP
方式访问，
发现其性能依旧和没有采用任何
MVC
框架的纯
JSP
之间存在好几倍的
差距，这又从另一个侧面证实了我们刚才得出结论，
struts2
性能的瓶颈不在于它的多例
Action
模式。
5.SpringMVC3
的性能略逊于
struts1
，但基本是同级别的，这让人眼前一亮，
springMVC
有
着不比
struts2
差的开发效率和解耦度，
但性能却是
struts2
的好几倍，
这让我们灰常振奋，
SpringMVC
无疑又是项目开发的一个好的选择。
唯一的问题就是，
目前国内使用面还不太多，
各方面的参考资料相对较少，上手的话可能要稍微难点。
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;