在當(dāng)今的MVC framework里，似乎Webwork2逐漸成為主流， Webwork2+SpringFramework的組合變得越來越流行。這似乎意味著Spring自帶的MVC framework遠(yuǎn)比Webwork2差，所以大家紛紛用Webwork2來代替。確實，Spring的MVC framework不算是整個Spring的核心部件，但它的威力卻超過了很多人的想象。很多人包括xiecc認(rèn)為Spring的MVC framework是非常優(yōu)秀的，甚至比Webwork2更優(yōu)秀。

下面列舉一下Spring的MVC framework在設(shè)計時做出的一些重要的決定，并將之和相關(guān)的MVC framework如Webwork2或struts進(jìn)行對比:

一、Spring的整個MVC配置是基于IOC容器的

與struts或webwork2相比，這是一個ms有點奇怪的決定，看一下Spring MVC的配置文件，最先看到的不是action或者form，而是一些有著特定名字的bean，Bean下面的配置是一些簡單或有點復(fù)雜的屬性。我們看到的是機器更容易的數(shù)據(jù)結(jié)構(gòu)，而不是人更容易理解的元素。

但是這恰恰是Spring的MVC強大的根源!因為它的配置就是Spring的核心IOC容器的配置，這意味著所有IOC容器的威力都可以在這里展現(xiàn)，我們可以為所欲為地對Spring MVC進(jìn)行擴展和增強，我們可以完成在其它MVC framwork中很多難以想象的任務(wù)。想擴展新的URL映射方式嗎?要換一個themeResolver或LocalReolver的實現(xiàn)嗎?想在頁面中顯示新類型的View(比如說RDF，呵呵，一個小秘密:xiecc是研究語義網(wǎng)的，雖然成天不務(wù)正業(yè)，不寫論文，只寫八卦)?甚至想直接在Controller里定義AOP嗎?這些對Spring的MVC來說都是小菜一碟。

我沒有仔細(xì)研究過Webwork2的擴展機制，我知道通過Webwork2的interceptor機制，可以進(jìn)行很多的擴展，甚至有一個簡單簡單的IOC容器。但不管它有多強大，提供了多少擴展點。它的威力都很難和真正的IOC容器相比。而struts的plugin功能則是出名的濫，雖然它也提供了plugin機制。

Spring采用IOC配置的另一個原因是使Spring的MVC與Spring的IOC容器的整合變得非常的容易。Spring提供了與struts與webwork2的整合，但是這樣整合都需要在進(jìn)行間接的包裝，感覺總不是很自然。而且還會導(dǎo)致一個概念多個配置，webwork2就需要在Spring里配置bean，再配置自己的xwork文件。想象一下吧，我們的bean直接就是一個controller,直接可以完成MVC的所有任務(wù),這是多少爽的感覺。

Rod Johnson采用IOC容器來實現(xiàn)的另一個原因是這會減少好多開發(fā)工作量。看一下urlMapping吧，它提供的property本身就是一個HashMap，只有配置完成，我們的bean里的數(shù)據(jù)就自然存在了，哈哈，好爽吧。不用象struts那樣解析XML，再把它的內(nèi)容一項一項地讀到HashMap里。

雖然這樣的配置會有點怪異，但假如我們對Spring的IOC容器非常熟悉的話，會發(fā)現(xiàn)它非常的親切，也非常的簡單。

最后是一個簡單的小秘密，Spring怎么知道某個bean的配置就是urlMapping?另一個bean的配置就是viewResolver?其實很簡單，把所有的bean全部讀到內(nèi)存里，然后通過bean的名字或類型去找就行了。通過名字去找就是簡單的getBean方法，通過類型去找則使用了BeanFactoryUtils.beansOfTypeIncludingAncestors的靜態(tài)方法。

二、Spring提供了明確的Model, View概念和相應(yīng)的數(shù)據(jù)結(jié)構(gòu)

在Spring里有一個有趣的數(shù)據(jù)類型叫做ModelAndView，它只是簡單地把要顯示的數(shù)據(jù)和顯示的結(jié)果封裝在一個類里。但是它卻提供了明確的MVC概念，尤其是model概念的強化，使程序的邏輯變得更清晰了。

記得以前在Struts里寫程序里的時候，為了顯示數(shù)據(jù)經(jīng)常自己把東西放到HttpSession或HttpServletRequest里(或set到form里，雖然不太有用)，這造成了model概念的模糊，而且也導(dǎo)致了struts與JSP頁面的緊耦合。假如我們要替換成Veloctiy,就得另外加一個plugin,因為在velocity里數(shù)據(jù)是不需要不放到request里的。

Webwork2里強調(diào)的是與Web framework解耦和它的command模式的簡單性，因此在它的action里只有簡單的get或set方法，假如返回數(shù)據(jù)，也只是簡單地返回一個String。當(dāng)然這樣的實現(xiàn)有它的好處，但是它淡化了model和view的概念。Rod Johnson認(rèn)為Webwork2里的Action同時包含了Action和Model的職責(zé)，這樣一個類的職責(zé)太多，不是一個很好的設(shè)計。當(dāng)然Jason Carreira不太認(rèn)同這種觀點，因為Action里的model對象完成可以delege給其它對象。但不管怎樣，這種爭論的根源在于Webwork2里淡化了model, view甚至web的概念。仁者見仁，智者見智，最后的結(jié)果還是看個人喜歡好吧。

三、Spring的Controller是Singleton的，或者是線程不安全的

和Struts一樣，Spring的Controller是Singleton的，這意味著每個request過來，系統(tǒng)都會用原有的instance去處理，這樣導(dǎo)致了兩個結(jié)果:我們不用每次創(chuàng)建Controller，減少了對象創(chuàng)建和垃圾收集的時間;由于只有一個Controller的instance，當(dāng)多個線程調(diào)用它的時候，它里面的instance變量不是線程安全的。

這也是Webwork2吹噓的地方，它的每個Action都是線程安全的。因為每過來一個request，它就創(chuàng)建一個Action對象。由于現(xiàn)代JDK垃圾收集功能的效率已經(jīng)不成問題，所以這種創(chuàng)建完一個對象就扔掉的模式也得到了好多人的認(rèn)可。Rod Johnson甚至以此為例證明J2EE提供的object pool功能是沒多大價值的。

但是當(dāng)人們在吹噓線程安全怎么怎么重要的時候，我想請問有多少人在多少情況下需要考慮線程安全?Rod Johnson在分析EJB的時候也提出過其它問題，并不是沒有了EJB的線程安全魔法，世界就會滅亡的，大多數(shù)情況下，我們根本不需要考慮線程安全的問題，也不考慮object pool。因為我們大多數(shù)情況下不需要保持instance狀態(tài)。

至少我寫了那么多的struts Action，寫了那么多的Spring Controller，幾乎沒有碰到需要在instance變量保持狀態(tài)的問題。當(dāng)然也許是我寫的代碼不夠多，Struts的設(shè)計者Craig R. McClanahan曾經(jīng)說當(dāng)時他設(shè)計struts時有兩個條件不成熟:當(dāng)時沒有測試驅(qū)動開發(fā)的概念;當(dāng)時JVM的垃圾收集性能太次。假如現(xiàn)在重新設(shè)計的話，他也會采用每個request生成一個新對象的設(shè)計方法，這樣可以解決掉線程安全的問題了。

四、Spring不象Webwork2或tapestry那樣去隱藏Servlet相關(guān)的元素如HttpServletRequest或HttpServletResponse

這又是一個重要的設(shè)計決定。在Webwork2里我們沒有HttpServletRequest或者HttpServletResponse，只有g(shù)etter, setter或ActionContext里數(shù)據(jù)，這樣的結(jié)果導(dǎo)致一個干凈的Action，一個與Web完全無關(guān)的Action，一個可以在任何環(huán)境下獨立運行的bean。那么Webwork2的這樣一個基于Command模式的Action究竟給我們帶來了什么?我想主要有兩點:

1、它使我們的Action可以非常容易地被測試。

2、用戶可以在Action里添加業(yè)務(wù)邏輯，并被其它類重用。

然而仔細(xì)跟Spring比較一下，我們就會發(fā)現(xiàn)這兩點功能所帶來的好處其實并不象我們想象的那么顯著。Spring的Controller類也可以非常輕松被測試，看一下spring-mock下面的包吧，它提供的MockHttpServletRequest, MockHttpServletResponse還有其它一些類讓測試Controller變得異常輕松。再看一下Action里的業(yè)務(wù)邏輯吧，Jason Carreira曾經(jīng)說我們可以盡情地在Webwork2的Action里加業(yè)務(wù)邏輯，因為Action是不依賴于Web的。但是有多少人真正往Action里加業(yè)務(wù)邏輯的?大多數(shù)人都會業(yè)務(wù)邏輯delegate給另一個Service類或Manager類。因為我們很清楚，往Action里加業(yè)務(wù)邏輯會使整個體系的分層架構(gòu)變得不清晰，不管怎樣，Web層就是Web層，業(yè)務(wù)層就是業(yè)務(wù)層，兩者的邏輯混在一起總會帶來問題的。而且往Action里加業(yè)務(wù)邏輯會使用這個Action類變得龐大，Webwork2的Action是每個request都創(chuàng)建實例的，盡管帶來的性能影響不太大，但并不表示每次都要把業(yè)務(wù)邏輯再new出來，業(yè)務(wù)邏輯在大多數(shù)的情況下應(yīng)該是單例的。

不把request和response展現(xiàn)給用戶當(dāng)然還會帶來功能上的損失，也許一般的場合，用用webwork2提供的接口已經(jīng)足夠了，但有時我們必須要知道request和response才能發(fā)揮出更大的威力。比如我以前的一個項目里有一個通過遞歸動態(tài)生成的樹狀結(jié)構(gòu)的頁面，在jsp頁面上顯示遞歸是痛苦或不可能的，因此我用response直接write出頁面，這在spring里很easy，但在webwork里可能比較難了(偶不敢肯定，偶研究得不夠深，也許高手是有辦法的)。

五、Spring提供了不錯但不夠充分的interceptor機制

回頭看一下struts，它在架構(gòu)里甚至沒有給我們提供hook point的機會，我們沒有任何機會加入自己的interceptor。我們只能通過重載struts的RequestProcessor類來進(jìn)行一點有限的擴展。

到了Webwork2，似乎interceptor一下子成了整個Framework的核心，除了Action的核心部件，其它所有的東西都是interceptor。它的超強的interceptor功能使們擴展整個架構(gòu)變得非常方便。有人稱這種interceptor為AOP，Jason Carreira則自豪地宣稱這個叫做pragamtic AOP。我不認(rèn)同這是AOP，它只是簡單的interceptor機制。但不管如何，它的interceptor確實有強大的功能。

Spring也提供了它的interceptor機制，它的HandlerInterceptor三個interceptor方法:peHandle, postHandle, afterCompletion。分別對應(yīng)Controller執(zhí)行前，Controller執(zhí)行后和page render之后。雖然大多數(shù)情況下已經(jīng)夠用，但是從功能上來說顯然它沒有Webwork2強大。從AOP的角度來看，它沒有提供around interceptor，而只有before與after interceptor。這意味著我們無法在interceptor前后保持狀態(tài)，最簡單的情況假如我們要計算一個Controller的執(zhí)行時間，我們必須在執(zhí)行完before后把begintime這個狀態(tài)保持住，再在after里把它調(diào)出來，但是顯然這個狀態(tài)保持會是個問題，我們不能把它放到instance變量里，因為interceptor不是線程安全的。也許通過ThreadLocal可以解決這個問題，但是如此簡單的功能要用到這樣的方法來處理，顯然這個Interceptor本身設(shè)計上還是有點問題的。

六、Spring提供了MultiActionController，使它可以在一個類里包含多個Action

這個設(shè)計和struts的DispatchAction有點類似，只不過提供了更靈活的機制。當(dāng)我們的項目變大的時候，把功能類似的方法放到同一個Action里完全值得的!Webwork2缺少這樣的機制。假如看一下Spring的源代碼，會發(fā)現(xiàn)其實實現(xiàn)MultiActionController的工作量相當(dāng)?shù)纳伲徊贿^是用反射機制把解析出來的方法名執(zhí)行一下就完事了。其實Webwork2也完全可以提供這樣的機制。雖然從設(shè)計上來說確實不是很優(yōu)雅，但是它確實很有用。

七、Spring提供了更多的選擇方式

看看Spring里提供的Controller吧，它提供了好多不同的Controller類。要生成Wizard嗎?要專門用于提交form的Controller嗎?要執(zhí)多個方法的類嗎?Spring提供了豐富的子類來擴展這些選擇。當(dāng)然我們還可以很輕松地自己擴展這些功能。

再看看Spring的ViewResolver吧， 它提供了無數(shù)不同類型的ViewResolver。更重要的是我們自定義我們的頁面映射方式。看看strtus，看看webwork2，都會存在頁面與forward name的一層間接轉(zhuǎn)換，我們必須在配置文件里配置好某個字符串(典型的是success)對應(yīng)的是那個頁面。但是Spring里我們有了更大的自由度，我們可以采用webwork2的策略，也可以采用更簡單的策略，如將JSP文件名去掉擴展名的映射方法。也許有人認(rèn)為這種映射方式很幼稚，但是我覺得它是非常有用的方式，即使在大項目里。

還有新的擴展嗎?看看Spring Web Flow吧，它是SpringFramework的子項目。它為一長串的基于頁面流的Wizard頁面提供了可配置的實現(xiàn)方式。在Spring 1.3里，它將是SpringFramework的一部分。

八、Spring的tag

盡管Spring的tag數(shù)量上少得可憐，但它卻是精心設(shè)計的。它的目標(biāo)很簡單:讓美工可以輕松地編輯頁面。因為在Spring的頁面里Text仍然是Text，checkbox仍然是CheckBox，而不象在struts或webwork2中的Tag。它只是用Springbind對輸入內(nèi)容進(jìn)行了一下包裝。所以盡管頁面顯示代碼上會比Webwork2多，但這絕對是有價值的。

在接下來的幾章里，我會分析一下Spring是如何讓我們的Web應(yīng)用不需要知道ApplicationContext就能夠訪問IOC容器的，然后會對Spring的設(shè)計和執(zhí)行過程進(jìn)行簡單的源碼分析，然后給出幾個擴展Spring MVC的方法。