|
參見：http://blog.csdn.net/generalyy0/article/details/7003974 Struts2與Spring MVC的差別 ======================================================= Struts2框架是類級別的攔截，每次來了請求就創(chuàng)建一個(gè)Action，然后調(diào)用setter、getter方法把request中的數(shù)據(jù)注入。Struts2實(shí)際上是通過setter、getter方法與request打交道的。Struts2中，一個(gè)Action對象對應(yīng)一個(gè)request上下文。 Spring MVC不同，Spring MVC是方法級別的攔截，攔截到方法后根據(jù)參數(shù)上的注解，把request數(shù)據(jù)注入進(jìn)去。Spring MVC中，一個(gè)方法對應(yīng)一個(gè)request上下文。 整理一下，Struts2是類級別的攔截， 一個(gè)類對應(yīng)一個(gè)request上下文，Spring mvc是方法級別的攔截，一個(gè)方法對應(yīng)一個(gè)request上下文，而方法同時(shí)又跟一個(gè)url對應(yīng)。所以說從架構(gòu)本身上 spring3 mvc就容易實(shí)現(xiàn)restful url ，而struts2的架構(gòu)實(shí)現(xiàn)起來要費(fèi)勁 ，因?yàn)閟truts2 action的一個(gè)方法可以對應(yīng)一個(gè)url ，而其類屬性卻被所有方法共享，這也就無法用注解或其他方式標(biāo)識其所屬方法了 。 ======================================================== Spring MVC的方法之間基本上獨(dú)立，獨(dú)享request response數(shù)據(jù)，請求數(shù)據(jù)通過參數(shù)獲取，處理結(jié)果通過ModelMap交回給框架，方法之間不共享變量。 Struts2搞的就比較亂，雖然方法也是獨(dú)立的，但其所有Action變量是共享的。這不會(huì)影響程序運(yùn)行，卻給編碼讀程序帶來麻煩。 ======================================================== Spring MVC的驗(yàn)證是一個(gè)亮點(diǎn)，支持JSR303，處理ajax的請求更是方便，只需要一個(gè)注解@ResponseBody，然后直接返回響應(yīng)文本即可。
參加：http://blog.csdn.net/gstormspire/article/details/8239182 下面這些東西基本都是我從網(wǎng)上粘貼過來的，沒有那么多耐心和時(shí)間一個(gè)字一個(gè)字的敲了，但是基本能表明我選擇SpringMVC的思路和原因。
把這張圖放在這里，我是想說SpringMVC和Struts2真的是不一樣的，雖然在都有著核心分發(fā)器等相同的功能組件（這些由MVC模式本身決定的）。
為什么SpringMVC會(huì)贏得最后的勝利呢？談幾點(diǎn)我自己的看法：
第一、MVC框架的出現(xiàn)是為了將URL從HTTP的世界中映射到JAVA世界中，這是MVC框架的核心功能。而在URL這一點(diǎn)SpringMVC無疑更加優(yōu)雅。
第二、從設(shè)計(jì)實(shí)現(xiàn)角度來說，我覺得SpringMVC更加清晰。即使我們?nèi)Ρ萐truts2的原理圖和SpringMVC的類圖，它依然很讓人困惑，遠(yuǎn)沒有SpringMVC更加直觀：
SpringMVC設(shè)計(jì)思路：將整個(gè)處理流程規(guī)范化，并把每一個(gè)處理步驟分派到不同的組件中進(jìn)行處理。 這個(gè)方案實(shí)際上涉及到兩個(gè)方面： l 處理流程規(guī)范化 —— 將處理流程劃分為若干個(gè)步驟（任務(wù)），并使用一條明確的邏輯主線將所有的步驟串聯(lián)起來 l 處理流程組件化 —— 將處理流程中的每一個(gè)步驟（任務(wù)）都定義為接口，并為每個(gè)接口賦予不同的實(shí)現(xiàn)模式 處理流程規(guī)范化是目的，對于處理過程的步驟劃分和流程定義則是手段。因而處理流程規(guī)范化的首要內(nèi)容就是考慮一個(gè)通用的Servlet響應(yīng)程序大致應(yīng)該包含的邏輯步驟： l 步驟1—— 對Http請求進(jìn)行初步處理，查找與之對應(yīng)的Controller處理類（方法） ——HandlerMapping l 步驟2—— 調(diào)用相應(yīng)的Controller處理類（方法）完成業(yè)務(wù)邏輯 ——HandlerAdapter l 步驟3—— 對Controller處理類（方法）調(diào)用時(shí)可能發(fā)生的異常進(jìn)行處理 ——HandlerExceptionResolver l 步驟4—— 根據(jù)Controller處理類（方法）的調(diào)用結(jié)果，進(jìn)行Http響應(yīng)處理 ——ViewResolver
正是這基于組件、接口的設(shè)計(jì)，支持了SpringMVC的另一個(gè)特性：行為的可擴(kuò)展性。
第三、設(shè)計(jì)原則更加明朗。 【Open for extension /closed for modification】 這條重要的設(shè)計(jì)原則被寫在了Spring官方的reference中SpringMVC章節(jié)的起始段： A key design principle in SpringWeb MVC and in Spring in general is the “Open for extension, closed for modification” principle. 并且重點(diǎn)很好地體現(xiàn)在SpringMVC的實(shí)現(xiàn)當(dāng)中，可以擴(kuò)展，但卻不能改變。我曾經(jīng)擴(kuò)展過Spring的IOC、AOP功能，這一點(diǎn)SpringMVC應(yīng)該和Spring一脈相承。
第四、組件化的設(shè)計(jì)方案和特定的設(shè)計(jì)原則讓SpringMVC形散神聚。
SpringMVC是一個(gè)基于組件的開發(fā)框架，組件的不同實(shí)現(xiàn)體系構(gòu)成了“形”；組件的邏輯串聯(lián)構(gòu)成了“神”。因此，“形散神不散”： SpringMVC的邏輯主線始終不變，而行為模式卻可以多種多樣。 第五、更加貼合Web發(fā)展的趨勢，這個(gè)更加虛了，不再展開說這個(gè) 問題了。
第六、技術(shù)上的放緩導(dǎo)致了程序員對Struts2失去了熱情，導(dǎo)致SpringMVC依靠自身的努力和Spring的口碑，逐漸顯露了自身的優(yōu)勢和特點(diǎn)。
為什么SpringMVC會(huì)贏得最后的勝利呢？最后，我們不妨想一想Struts2是怎樣流行起來的！ 我自己是從Struts1用過來的，后來Struts1的問題很明顯了，開源社區(qū)出現(xiàn)了很多的MVC框架，最為突出的是Webwork2。 Webwork2探索了一條與傳統(tǒng)Servlet模型不同的解決方案，逐漸被大家熟識和理解，不斷發(fā)展并得到了廣大程序員的認(rèn)可。它以優(yōu)秀的設(shè)計(jì)思想和靈活的實(shí)現(xiàn)，吸引了大批的Web層開發(fā)人員投入它的 懷抱。 Apache社區(qū)與Opensymphony宣布未來的Struts項(xiàng)目將與Webwork2項(xiàng)目合并，并聯(lián)合推出Struts2。 Struts2能夠在一個(gè)相當(dāng)長的時(shí)間段內(nèi)占據(jù)開發(fā)市場主導(dǎo)地位的重要原因在于其技術(shù)上的領(lǐng)先優(yōu)勢。而這一技術(shù)上的領(lǐng)先優(yōu)勢，突出表現(xiàn)為對Controller的徹底改造： public class UserController { private User user public String execute() { // 這里加入業(yè)務(wù)邏輯代碼 return "success"; } }
從上面的代碼中，我們可以看到Webwork2 /Struts2對于Controller最大的改造有兩點(diǎn)：
這兩大改造被看作是框架的神來之筆。因?yàn)橥ㄟ^這一改造，整個(gè)Controller類徹底與Web容器解耦，可以方便地進(jìn)行單元測試。而擺脫了Servlet束縛的Controller，也為整個(gè)編程模型賦予了全新的定義。從引入新的編程元素的角度來說，Webwork2 / Struts2無疑也是成功的。因?yàn)樵趥鹘y(tǒng)Servlet模式中的禁地Controller中的屬性變量被合理利用了起來作為請求處理過程中的數(shù)據(jù)部分。這樣的改造不僅使得表達(dá)式引擎能夠得到最大限度的發(fā)揮，同時(shí)使得整個(gè)Controller看起來更像是一個(gè)POJO。因而，這種表現(xiàn)形態(tài)被筆者冠以的名稱 是：POJO實(shí)現(xiàn)模式。POJO實(shí)現(xiàn)模式是一種具有革命性意義的模式，因?yàn)樗軌虬呀怦詈线@樣一個(gè)觀點(diǎn)發(fā)揮到極致。從面向?qū)ο蟮慕嵌葋砜?，POJO模式無疑也是所有程序員所追求的一個(gè)目標(biāo)。這也就是Webwork2 /Struts2那么多年來經(jīng)久不衰的一個(gè)重要原因。 所以，我們看到第一條原因是Struts2依靠技術(shù)上的革新贏得了程序員的青睞。但是，這些年來Struts2在技術(shù)革新上的作為似乎步子就邁得比較小。我們可以看到，在JDK1.5普及之后，Annotation作為一種新興的Java語法，逐漸 被大家熟知和應(yīng)用。這一點(diǎn)上SpringMVC緊跟了時(shí)代的潮流，直接用于請求-響應(yīng)的映射。而Struts2卻遲遲無法在單一配置源的問題上形成突破。 當(dāng)然，這只是技術(shù)革新上的一個(gè)簡單的例子，其他的例子還有很多。 至少給人的感覺是這樣的。在這一點(diǎn)上Struts并不是很沾光，因?yàn)镾pring的口碑和影響力也客觀程度上加深了大家對SpirngMVC是技術(shù)領(lǐng)導(dǎo)者的印象。 |
|
|
