WEB框架比較WEB框架的實(shí)質(zhì)今天分享的目的嘗試透過(guò)紛繁的表象，分析各種Web應(yīng)用框架的本質(zhì)。SpringMVCTapestryWebwork粗略了解各框架的優(yōu)缺點(diǎn)?？紤]進(jìn)一步發(fā)展我們的框架的方向。WEB請(qǐng)求—響應(yīng)瀏覽器HTTP請(qǐng)求HTTP響應(yīng)App.Server黑箱一般WEB請(qǐng)求處理過(guò)程解析request解析request包括：解析URL解析HTTPheaders解析querystring解析request工作主要是由servletcontainer完成的：根據(jù)URL，調(diào)用適當(dāng)?shù)膚ebapp將URL匹配web.xml中的servlet-mapping，并調(diào)用適當(dāng)?shù)膕ervlet根據(jù)HTTPmethod，調(diào)用servlet中適當(dāng)?shù)姆椒ā．?dāng)需要時(shí)，解析querystring應(yīng)用程序/框架需要做的工作：告訴servletcontainer，當(dāng)以何種locale/編碼來(lái)解析querystring解析multipart/form-data的數(shù)據(jù)（upload）分析request分析request是指：根據(jù)前一步解析而得的信息，進(jìn)一步確定應(yīng)該如何來(lái)處理這個(gè)request。最常見(jiàn)的方式，是根據(jù)URL中的某部分，或者某參數(shù)的值，來(lái)取得某個(gè)業(yè)務(wù)模塊，并執(zhí)行之。執(zhí)行業(yè)務(wù)模塊這一步是應(yīng)用程序員需要做的事，主要包括：分析/取得WEB參數(shù)驗(yàn)證表單根據(jù)請(qǐng)求的內(nèi)容，執(zhí)行具體的業(yè)務(wù)邏輯（例如從數(shù)據(jù)庫(kù)中取得數(shù)據(jù)，或保存數(shù)據(jù)）決定要顯示的頁(yè)面，并準(zhǔn)備好頁(yè)面顯示所必須的一些參數(shù)。除了上述這些內(nèi)容，還可能需要考慮一些非功能性的需求，例如：頁(yè)面的安全特性（是不是必須登錄？是否重復(fù)提交？等）頁(yè)面的流程（頁(yè)面之間的關(guān)系、狀態(tài)的保存等）重定向有時(shí)不一定直接顯示頁(yè)面，而是將控制轉(zhuǎn)發(fā)給另一個(gè)模塊/應(yīng)用。內(nèi)部重定向，對(duì)瀏覽器不可知，將控制轉(zhuǎn)發(fā)給另一個(gè)模塊外部重定向，通過(guò)瀏覽器定向，將控制轉(zhuǎn)發(fā)給其它應(yīng)用可選操作異常處理日志顯示錯(cuò)誤頁(yè)面……時(shí)間戳檢查通過(guò)時(shí)間戳檢查，可以加快響應(yīng)的時(shí)間，減少不必要的業(yè)務(wù)操作需要HTTP協(xié)議配合：If-modified-since等。Portlet支持Web框架實(shí)質(zhì)——擴(kuò)展現(xiàn)在有很多opensource的Web框架，例如：SpringMVCTapestryWebwork共同點(diǎn)：均實(shí)現(xiàn)了M-V-C設(shè)計(jì)模式。在整個(gè)請(qǐng)求處理的流程中，提供多種擴(kuò)展點(diǎn)，來(lái)實(shí)現(xiàn)具體的業(yè)務(wù)邏輯。盡可能簡(jiǎn)化開(kāi)發(fā)應(yīng)用的復(fù)雜性。那么不同的Web框架，它們之間有什么不同呢？提供擴(kuò)展的方式不同擴(kuò)展點(diǎn)的功能和數(shù)量不同Web框架的實(shí)質(zhì)——組合從另一個(gè)角度看其實(shí)一個(gè)框架就是一個(gè)模型模型由很多部分組合而成有哪些部分、如何組合？這些答案的不同就構(gòu)成了各種不同框架的不同。但不同的實(shí)現(xiàn)，為的是完成類似的任務(wù)我們將從分析每個(gè)框架的模型來(lái)入手現(xiàn)代“組合”技術(shù)的基礎(chǔ)不約而同，今天我們要分析的三個(gè)Web框架，都為自己建立了一個(gè)與Web無(wú)關(guān)的“組合”對(duì)象的平臺(tái)。SpringMVC——以Springframework為基礎(chǔ)Tapestry——以Hivemind為基礎(chǔ)Webwork——以Xwork為基礎(chǔ)這個(gè)基礎(chǔ)平臺(tái)的不同，很大程度地影響了Web框架本身的風(fēng)格。平臺(tái)的優(yōu)點(diǎn)，直接帶給Web框架獨(dú)特的價(jià)值。平臺(tái)的缺點(diǎn)，也帶給相應(yīng)Web框架有時(shí)是難以克服的缺陷。SpringMVC的模型SpringMVC的模型SpringMVC的表單處理過(guò)程Tapestry的模型Tapestry的request處理流程(續(xù))Webwork的模型對(duì)比——分析requestSpringMVCSpring使用HandlerMapping來(lái)匹配URL和controller。Spring2.0支持ControllerClassNameHandlerMapping，就是利用URL命名規(guī)范來(lái)映射controller，使配置文件被簡(jiǎn)化。例如：WelcomeController->/welcome/*。利用HandlerAdapter分離框架對(duì)具體Controller實(shí)現(xiàn)的依賴。最常用的是SimpleControllerHandlerAdapter。Tapestry通過(guò)ServiceEncoder來(lái)定制URL，也就是將URL翻譯成參數(shù)表，然后利用這些參數(shù)來(lái)確定service、page等。類似Spring的HandlerAdapter，Tapestry也支持任意數(shù)量的EngineService。最常用來(lái)顯示頁(yè)面的service叫做PageService。對(duì)比——執(zhí)行業(yè)務(wù)模塊SpringMVCSpring的業(yè)務(wù)模塊為controllerSpring提供了很多種controller，比較有用的有：MultiActionController、CommandController、FormController、WizardController。大部分controller支持從querydata生成command對(duì)象?？梢酝ㄟ^(guò)注入的方式來(lái)裝配controller。Spring2.0支持session和requestscope的對(duì)象注入。Spring未提供表單驗(yàn)證的功能，需要通過(guò)硬編碼來(lái)完成表單的驗(yàn)證。Controller支持interceptors，可以用它來(lái)完成一些特別的功能，例如：頁(yè)面安全性。由于Spring本身的功能，在controller里調(diào)用業(yè)務(wù)邏輯非常容易。對(duì)比——執(zhí)行業(yè)務(wù)模塊TapestryTapestry的業(yè)務(wù)模塊為page和component。利用ognl的功能，可以在頁(yè)面模板中直接將用戶的輸入值注入到pageproperties中。同樣，通過(guò)注入（pagespec.或annotation），page可以獲得容器中的任意對(duì)象。沒(méi)有直接的方法可以對(duì)page和component創(chuàng)建interceptor，如果要實(shí)現(xiàn)諸如頁(yè)面安全的功能，必須通過(guò)基類，或通過(guò)pipeline來(lái)做。Tapestry的表單驗(yàn)證是通過(guò)頁(yè)面控件來(lái)做的。對(duì)比——顯示頁(yè)面TapestryTapestry最強(qiáng)的技術(shù)就是它的基于控件的模板技術(shù)：和標(biāo)準(zhǔn)的HTML兼容，可以使用dreamweaver等HTML編輯器來(lái)編輯它的模板文件?？芍赜玫目丶ɡ纾篋atePicker），支持JavaScript。頁(yè)面的出錯(cuò)信息很詳細(xì)。通過(guò)可重用的控件（例如：常見(jiàn)的border.jwc控件），可以方便地實(shí)現(xiàn)頁(yè)面布局。Tapestry不直接支持其它頁(yè)面顯示技術(shù)。其它關(guān)注點(diǎn)：pagedriven所謂driven，就是在開(kāi)發(fā)應(yīng)用時(shí)，以頁(yè)面為主導(dǎo)，程序?yàn)檩o助。這種模式可以比較快和直觀地開(kāi)發(fā)應(yīng)用。Spring和webwork都不支持這種模式。Spring2.0雖然增加了CoC的功能（ConventionoverConfiguration），但為了實(shí)現(xiàn)它仍然需要相當(dāng)多的配置。Tapestry可以做到driven。在tapestry中，只要?jiǎng)?chuàng)建一個(gè)普通的html頁(yè)面，就可以顯示出來(lái)——即使page的程序還沒(méi)寫(xiě)。其它關(guān)注點(diǎn)：侵入性所謂侵入性，就是指應(yīng)用的代碼依賴多少框架的代碼。最理想的情況，是沒(méi)有依賴，但這個(gè)很難做到。比較好的情況是只依賴一些特定的接口，而這些接口越簡(jiǎn)單越好，同時(shí)接口本身和框架之間也是松散耦合。這一點(diǎn)Spring做得比較好：首先，SpringMVC的核心Controller接口非常簡(jiǎn)單，只有一個(gè)方法。其次，Controller接口和SpringMVC之間的耦合只是通過(guò)一個(gè)HandlerAdapter完成的，除此之外沒(méi)有任何關(guān)聯(lián)。Tapestry的侵入性最大，但是據(jù)說(shuō)其后續(xù)版本將改良這一點(diǎn)，引入POJO編程。Webwork的侵入性也比較小，Action接口并不復(fù)雜。但Action接口是webwork的核心類，和webwork耦合很緊，所以其侵入性比Spring略大一些。較低的侵入性意味著較好的擴(kuò)展性、較易于測(cè)試、較好的系統(tǒng)結(jié)構(gòu)。過(guò)度追求低侵入性，也是有問(wèn)題的。因?yàn)榛诮涌诘木幊炭梢岳镁幾g器的檢查，而假設(shè)侵入性為零，那意味著連接口也不能用了，這樣就只好通過(guò)配置或者convention來(lái)定義規(guī)則，這樣不一定比使用接口要好。其它關(guān)注點(diǎn)：基于requestvs.基于對(duì)象Webwork、Spring都是基于request的Web框架。優(yōu)點(diǎn)：簡(jiǎn)單易用；對(duì)request和response有直接的控制。缺點(diǎn)：和WEB結(jié)合太緊；難以實(shí)現(xiàn)頁(yè)面/組件之間的關(guān)聯(lián)、重用等高級(jí)功能。Tapestry是基于Object的Web框架。優(yōu)點(diǎn)：易于實(shí)現(xiàn)頁(yè)面/組件的重用；可創(chuàng)建出非常復(fù)雜的可重用組件：DatePicker、Tree等，也可非常方便地實(shí)現(xiàn)JavaScript組件；書(shū)寫(xiě)頁(yè)面顯得很結(jié)構(gòu)化。缺點(diǎn)：對(duì)request和response沒(méi)有直接的控制，以至于做一些簡(jiǎn)單的HTTP操作也顯得很麻煩，例如：重定向；頁(yè)面過(guò)于結(jié)構(gòu)化，導(dǎo)致一些頁(yè)面顯得很笨拙。其它關(guān)注點(diǎn)：Servicemodelvs.BeanmodelServicemodel，就是像Tapestry所基于的Hivemind的模式。Beanmodel，就是像Webwork所基于的xwork，以及Spring的模式。Beanmodel可以看作是簡(jiǎn)化的Servicemodel，但servicemodel包含更多的內(nèi)容：Servicemodel最重要的一點(diǎn)是：Service的提供者和使用者，兩者權(quán)責(zé)的分離。另一個(gè)重要點(diǎn)是：Service包含一個(gè)service的定義，而bean只是一堆相對(duì)無(wú)意義的properties而已。兩者均支持IoC、AoP。但Servicemodel支持搭建更復(fù)雜的對(duì)象層次，而beanmodel只能在一個(gè)“平面”的層次中工作。這實(shí)際上是SpringMVC和Tapestry最本質(zhì)的區(qū)別。然而HiveMind的思路雖然絕妙，實(shí)現(xiàn)上卻還沒(méi)達(dá)到完美，以至于有的情況下會(huì)很麻煩。我們框架的發(fā)