建站
咨詢
售后
建站咨詢
新聞中心
在當今的MVC framework里，似乎Webwork2逐漸成為主流， Webwork2+SpringFramework的組合變得越來越流行。這似乎意味著Spring自帶的MVC framework遠比Webwork2差，所以大家紛紛用Webwork2來代替。確實，Spring的MVC framework不算是整個Spring的核心部件，但它的威力卻超過了很多人的想象。很多人包括xiecc認為Spring的MVC framework是非常優(yōu)秀的，甚至比Webwork2更優(yōu)秀。
十余年專注成都網(wǎng)站制作，企業(yè)網(wǎng)站建設，個人網(wǎng)站制作服務，為大家分享網(wǎng)站制作知識、方案，網(wǎng)站設計流程、步驟,成功服務上千家企業(yè)。為您提供網(wǎng)站建設,網(wǎng)站制作,網(wǎng)頁設計及定制高端網(wǎng)站建設服務,專注于企業(yè)網(wǎng)站建設,高端網(wǎng)頁制作,對戶外休閑椅等多個領域，擁有多年的網(wǎng)站維護經(jīng)驗。
下面列舉一下Spring的MVC framework在設計時做出的一些重要的決定，并將之和相關的MVC framework如Webwork2或struts進行對比：
一.Spring的整個MVC配置是基于IOC容器的
與struts或webwork2相比，這是一個ms有點奇怪的決定，看一下Spring MVC的配置文件，***看到的不是action或者form，而是一些有著特定名字的bean，Bean下面的配置是一些簡單或有點復雜的屬性。我們看到的是機器更容易的數(shù)據(jù)結(jié)構(gòu)，而不是人更容易理解的元素。
但是這恰恰是Spring的MVC強大的根源！因為它的配置就是Spring的核心IOC容器的配置，這意味著所有IOC容器的威力都可以在這里展現(xiàn)，我們可以為所欲為地對Spring MVC進行擴展和增強，我們可以完成在其它MVC framwork中很多難以想象的任務。想擴展新的URL映射方式嗎？要換一個themeResolver或LocalReolver的實現(xiàn)嗎？想在頁面中顯示新類型的View（比如說RDF，呵呵，一個小秘密：xiecc是研究語義網(wǎng)的，雖然成天不務正業(yè)，不寫論文，只寫八卦）？甚至想直接在 Controller里定義AOP嗎？這些對Spring的MVC來說都是小菜一碟。
我沒有仔細研究過Webwork2的擴展機制，我知道通過Webwork2的interceptor機制，可以進行很多的擴展，甚至有一個簡單簡單的IOC容器。但不管它有多強大，提供了多少擴展點。它的威力都很難和真正的IOC容器相比。而struts的plugin功能則是出名的濫，雖然它也提供了plugin機制。
Spring采用IOC配置的另一個原因是使Spring的MVC與Spring的IOC容器的整合變得非常的容易。Spring提供了與 struts與webwork2的整合，但是這樣整合都需要在進行間接的包裝，感覺總不是很自然。而且還會導致一個概念多個配置，webwork2就需要在Spring里配置bean，再配置自己的xwork文件。想象一下吧，我們的bean直接就是一個controller，直接可以完成MVC的所有任務，這是多少爽的感覺。
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概念和相應的數(shù)據(jù)結(jié)構(gòu)
在Spring里有一個有趣的數(shù)據(jù)類型叫做ModelAndView，它只是簡單地把要顯示的數(shù)據(jù)和顯示的結(jié)果封裝在一個類里。但是它卻提供了明確的MVC概念，尤其是model概念的強化，使程序的邏輯變得更清晰了。
記得以前在Struts里寫程序里的時候，為了顯示數(shù)據(jù)經(jīng)常自己把東西放到HttpSession或HttpServletRequest里（或set到form里，雖然不太有用），這造成了model概念的模糊，而且也導致了struts與JSP頁面的緊耦合。假如我們要替換成 Veloctiy，就得另外加一個plugin，因為在velocity里數(shù)據(jù)是不需要不放到request里的。
Webwork2里強調(diào)的是與Web framework解耦和它的command模式的簡單性，因此在它的action里只有簡單的get或set方法，假如返回數(shù)據(jù)，也只是簡單地返回一個 String.當然這樣的實現(xiàn)有它的好處，但是它淡化了model和view的概念。Rod Johnson認為Webwork2里的Action同時包含了Action和Model的職責，這樣一個類的職責太多，不是一個很好的設計。當然 Jason Carreira不太認同這種觀點，因為Action里的model對象完成可以delege給其它對象。但不管怎樣，這種爭論的根源在于 Webwork2里淡化了model， view甚至web的概念。仁者見仁，智者見智，***的結(jié)果還是看個人喜歡好吧。
三.Spring的Controller是Singleton的，或者是線程不安全的
和Struts一樣，Spring的Controller是Singleton的，這意味著每個request過來，系統(tǒng)都會用原有的 instance去處理，這樣導致了兩個結(jié)果：我們不用每次創(chuàng)建Controller，減少了對象創(chuàng)建和垃圾收集的時間；由于只有一個 Controller的instance，當多個線程調(diào)用它的時候，它里面的instance變量不是線程安全的。
這也是Webwork2吹噓的地方，它的每個Action都是線程安全的。因為每過來一個request，它就創(chuàng)建一個Action對象。由于現(xiàn)代JDK垃圾收集功能的效率已經(jīng)不成問題，所以這種創(chuàng)建完一個對象就扔掉的模式也得到了好多人的認可。Rod Johnson甚至以此為例證明J2EE提供的object pool功能是沒多大價值的。
但是當人們在吹噓線程安全怎么怎么重要的時候，我想請問有多少人在多少情況下需要考慮線程安全？Rod Johnson在分析EJB的時候也提出過其它問題，并不是沒有了EJB的線程安全魔法，世界就會滅亡的，大多數(shù)情況下，我們根本不需要考慮線程安全的問題，也不考慮object pool.因為我們大多數(shù)情況下不需要保持instance狀態(tài)。
至少我寫了那么多的struts Action，寫了那么多的Spring Controller，幾乎沒有碰到需要在instance變量保持狀態(tài)的問題。當然也許是我寫的代碼不夠多，Struts的設計者Craig R. McClanahan曾經(jīng)說當時他設計struts時有兩個條件不成熟：當時沒有測試驅(qū)動開發(fā)的概念；當時JVM的垃圾收集性能太次。假如現(xiàn)在重新設計的話，他也會采用每個request生成一個新對象的設計方法，這樣可以解決掉線程安全的問題了。
四.Spring不象Webwork2或tapestry那樣去隱藏Servlet相關的元素如HttpServletRequest或HttpServletResponse
這又是一個重要的設計決定。在Webwork2里我們沒有HttpServletRequest或者HttpServletResponse，只有getter， setter或ActionContext里數(shù)據(jù)，這樣的結(jié)果導致一個干凈的Action，一個與Web完全無關的Action，一個可以在任何環(huán)境下獨立運行的bean.那么Webwork2的這樣一個基于Command模式的Action究竟給我們帶來了什么？我想主要有兩點：
1.它使我們的Action可以非常容易地被測試。
2.用戶可以在Action里添加業(yè)務邏輯，并被其它類重用。
然而仔細跟Spring比較一下，我們就會發(fā)現(xiàn)這兩點功能所帶來的好處其實并不象我們想象的那么顯著。Spring的Controller類也可以非常輕松被測試，看一下spring-mock下面的包吧，它提供的MockHttpServletRequest， MockHttpServletResponse還有其它一些類讓測試Controller變得異常輕松。再看一下Action里的業(yè)務邏輯吧，Jason Carreira曾經(jīng)說我們可以盡情地在Webwork2的Action里加業(yè)務邏輯，因為Action是不依賴于Web的。但是有多少人真正往 Action里加業(yè)務邏輯的？大多數(shù)人都會業(yè)務邏輯delegate給另一個Service類或Manager類。因為我們很清楚，往Action里加業(yè)務邏輯會使整個體系的分層架構(gòu)變得不清晰，不管怎樣，Web層就是Web層，業(yè)務層就是業(yè)務層，兩者的邏輯混在一起總會帶來問題的。而且往Action里加業(yè)務邏輯會使用這個Action類變得龐大，Webwork2的Action是每個request都創(chuàng)建實例的，盡管帶來的性能影響不太大，但并不表示每次都要把業(yè)務邏輯再new出來，業(yè)務邏輯在大多數(shù)的情況下應該是單例的。
不把request和response展現(xiàn)給用戶當然還會帶來功能上的損失，也許一般的場合，用用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類來進行一點有限的擴展。
到了Webwork2，似乎interceptor一下子成了整個Framework的核心，除了Action的核心部件，其它所有的東西都是 interceptor.它的超強的interceptor功能使們擴展整個架構(gòu)變得非常方便。有人稱這種interceptor為AOP，Jason Carreira則自豪地宣稱這個叫做pragamtic AOP.我不認同這是AOP，它只是簡單的interceptor機制。但不管如何，它的interceptor確實有強大的功能。
Spring也提供了它的interceptor機制，它的HandlerInterceptor三個interceptor方法：peHandle， postHandle， afterCompletion.分別對應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本身設計上還是有點問題的。
六.Spring提供了MultiActionController，使它可以在一個類里包含多個Action
這個設計和struts的DispatchAction有點類似，只不過提供了更靈活的機制。當我們的項目變大的時候，把功能類似的方法放到同一個Action里完全值得的！Webwork2缺少這樣的機制。假如看一下Spring的源代碼，會發(fā)現(xiàn)其實實現(xiàn) MultiActionController的工作量相當?shù)纳伲徊贿^是用反射機制把解析出來的方法名執(zhí)行一下就完事了。其實Webwork2也完全可以提供這樣的機制。雖然從設計上來說確實不是很優(yōu)雅，但是它確實很有用。
七.Spring提供了更多的選擇方式
看看Spring里提供的Controller吧，它提供了好多不同的Controller類。要生成Wizard嗎？要專門用于提交form 的Controller嗎？要執(zhí)多個方法的類嗎？Spring提供了豐富的子類來擴展這些選擇。當然我們還可以很輕松地自己擴展這些功能。
再看看Spring的ViewResolver吧，它提供了無數(shù)不同類型的ViewResolver.更重要的是我們自定義我們的頁面映射方式。看看strtus，看看webwork2，都會存在頁面與 forward name的一層間接轉(zhuǎn)換，我們必須在配置文件里配置好某個字符串（典型的是success）對應的是那個頁面。但是Spring里我們有了更大的自由度，我們可以采用webwork2的策略，也可以采用更簡單的策略，如將JSP文件名去掉擴展名的映射方法。也許有人認為這種映射方式很幼稚，但是我覺得它是非常有用的方式，即使在大項目里。
還有新的擴展嗎？看看Spring Web Flow吧，它是SpringFramework的子項目。它為一長串的基于頁面流的Wizard頁面提供了可配置的實現(xiàn)方式。在Spring 1.3里，它將是SpringFramework的一部分。
八.Spring的tag
盡管Spring的tag數(shù)量上少得可憐，但它卻是精心設計的。它的目標很簡單：讓美工可以輕松地編輯頁面。因為在Spring的頁面里 Text仍然是Text，checkbox仍然是CheckBox，而不象在struts或webwork2中的Tag.它只是用Springbind對輸入內(nèi)容進行了一下包裝。所以盡管頁面顯示代碼上會比Webwork2多，但這絕對是有價值的。
在接下來的幾章里，我會分析一下Spring是如何讓我們的Web應用不需要知道ApplicationContext就能夠訪問IOC容器的，然后會對Spring的設計和執(zhí)行過程進行簡單的源碼分析，然后給出幾個擴展Spring MVC的方法。
文章名稱：SpringMVCframework深入總體分析
分享URL：http://www.5511xx.com/article/djedjpo.html
