Chan Chen Coding...

Java MVC 比较

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 urlstruts2是类级别的拦截,一个类对应一个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

:酷睿

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;

posted on 2013-05-04 16:21 Chan Chen 阅读(488) 评论(0)  编辑  收藏 所属分类: Architecture


只有注册用户登录后才能发表评论。


网站导航: