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;