從整體上來(lái)說(shuō)，webx框架是一個(gè)可定制可擴(kuò)展的javaEE框架。為什么說(shuō)它是可定制可擴(kuò)展的，其根本原因在于webx框架的層次性和繼承性的，webx分為3大層次，SpringExt，Webx Framework和Webx Turbine。從SpringExt到Webx Framework再到Webx Turbine，一層一層的擴(kuò)展，在原來(lái)的層次基礎(chǔ)上添加功能。從上層到下層整體來(lái)說(shuō)和繼承機(jī)制像類似，Webx Framework繼承了SpringExt，而Webx Turbine又繼承了Webx Framework。在繼承的過(guò)程中通過(guò)使用OCP原則使得子層次的結(jié)構(gòu)完全兼容父層次的結(jié)構(gòu)，只是在原來(lái)的結(jié)構(gòu)上添加了一些額外的功能。正是這種層次化，繼承化的框架結(jié)構(gòu)使得webx框架可定制和可擴(kuò)展。

因?yàn)槠淇啥ㄖ瓶蓴U(kuò)展的特點(diǎn)，在使用框架的時(shí)候可以只使用SpringExt框架，或者使用Webx Framework框架，或者使用全部的WebxTurbine框架。或者，可以在Webx Framework結(jié)構(gòu)上不使用Webx Turbine的那一套網(wǎng)頁(yè)渲染方式，而是用另外的一套網(wǎng)頁(yè)渲染方式。靈活性很強(qiáng)。

因?yàn)樗袑游鼋Y(jié)構(gòu)的原始結(jié)構(gòu)都是Spring，所以不管哪個(gè)層次的結(jié)構(gòu)，其框架的啟動(dòng)方式和服務(wù)方式是統(tǒng)一的。在應(yīng)用啟動(dòng)的時(shí)候，會(huì)加載一個(gè)Spring容器到內(nèi)存中，并且默認(rèn)的在容器中添加一些用于服務(wù)的Service Bean，這些Service Bean會(huì)通常在整個(gè)生命周期中存在并提供各項(xiàng)服務(wù)。對(duì)于不同的層次，其Service會(huì)有各種不同的擴(kuò)展，比如在SpringExt層次中有用于加載資源的ResourceLoaderService，在Webx Framwork層次中擴(kuò)展了用于控制整個(gè)應(yīng)用流程的Pipeline Service，在Webx Turbine層次中又?jǐn)U展了用于加載模塊的ModuleLoaderService。這些service都會(huì)有與其對(duì)應(yīng)的Service Bean在Spring容器加載的時(shí)候被添加到Spring容器中，有時(shí)候這些Service Bean也會(huì)被注入到應(yīng)用中具體的Bean中去，為其提供服務(wù)。

我們現(xiàn)在的項(xiàng)目中通常都是使用整個(gè)Webx 框架來(lái)進(jìn)行項(xiàng)目開發(fā)，所以對(duì)于之前提到的三層結(jié)構(gòu)，我們用的是最外層，即Webx Turbine結(jié)構(gòu)。對(duì)于每一層的service都可以進(jìn)行使用，這樣形成一個(gè)比較龐大的框架體系。用到的service如下：

• Form Service —— 提供基于HTML form的表單驗(yàn)證功能。
• Template Service —— 提供基于文本的模板渲染的功能。
• JSP Service —— 基于JSP的模板引擎，和Template Service配合，渲染JSP格式的模板文件。
• Velocity Service —— 基于 Velocity 的模板引擎，和Template Service配合，渲染Velocity格式的模板文件。
• Pipeline Service —— 讀取配置，創(chuàng)建pipeline。Pipeline是一種可配置的程序流程控制技術(shù)，被webx用來(lái)控制HTTP請(qǐng)求的流程。
• Mail Service —— 通過(guò)配置和編程的方法，方便地創(chuàng)建、發(fā)送、接收符合RFC標(biāo)準(zhǔn)的e-mail。
• Pull Service —— 實(shí)現(xiàn)Pull-MVC的設(shè)計(jì)模式。
• RunData Service —— 將HTTP請(qǐng)求中的諸多對(duì)象包裝成一個(gè)更易于使用的接口，并且對(duì)HTTP response實(shí)現(xiàn)了buffer機(jī)制，是頁(yè)面cache技術(shù)和頁(yè)面layout技術(shù)的基礎(chǔ)。
• Upload Service —— 處理multipart/form-data類型的HTTP request。
• URIBroker Service —— 動(dòng)態(tài)生成任意類型的 URL 和 URI 。

這些service各司其職，為我們提供有效的服務(wù)。我們?cè)趹?yīng)用中要使用這些service的時(shí)候需要在webx.xml中對(duì)其進(jìn)行配置，這樣在Spring容器加載的時(shí)候才能加載這些service，后面才可以對(duì)該service進(jìn)行使用。下面對(duì)幾個(gè)比較重要的service進(jìn)行描述。

資源表現(xiàn)形式的多樣性，給應(yīng)用程序的接口設(shè)計(jì)帶來(lái)一點(diǎn)麻煩，為了統(tǒng)一資源的獲取，Spring框架中提供這方面的服務(wù)，即Resource Loader，但是Resource Loader還存在一些不合理的地方，于是webx中提供了Resource Loading Service對(duì)資源進(jìn)行統(tǒng)一管理，在Resource Loading Service中可以包含多個(gè)不同的Resource Loader進(jìn)行資源的加載，使得加載資源具有多樣性，同時(shí)也很好的完成了資源加載的大部分功能。

并且在ResourceLoading的服務(wù)中添加了XML Shema及其解釋器，使得對(duì)于資源的裝配的配置文件寫起來(lái)更加清晰易讀，而且修改和維護(hù)性增強(qiáng)。

RequestContexts Service是對(duì)servlet中的Filter的擴(kuò)展，作用是對(duì)請(qǐng)求進(jìn)行預(yù)處理。該服務(wù)負(fù)責(zé)訪問(wèn)和修改request和response，但是不負(fù)責(zé)改變應(yīng)用執(zhí)行的流程，改變應(yīng)用執(zhí)行的流程則是另一個(gè)對(duì)Filter擴(kuò)展的Service: Pipeline Service來(lái)完成。

Request ContextsService的核心是Request Contexts，Request Context是對(duì)HttpServletRequest和HttpServletResponse這兩個(gè)對(duì)象的封裝，將有多個(gè)Request Context嵌套，就好像一個(gè)filter chain一樣，從內(nèi)到外一步一步執(zhí)行，直到最后形成一個(gè)較大的Request Context用來(lái)處理，在處理結(jié)束以后，再?gòu)耐獾絻?nèi)一步一步執(zhí)行，將Response返回。

Pipeline service通過(guò)Value的控制，提供應(yīng)用執(zhí)行的流程，但不關(guān)心request和response。Request和Response的處理交給 Request Contexts Service來(lái)做。

Pipeline service控制著整個(gè)應(yīng)用的運(yùn)行流程，Pipeline和Action一起在MVC結(jié)構(gòu)中起到了一個(gè)Controller的作用，對(duì)整個(gè)應(yīng)用的走向進(jìn)行控制。

Form Service是對(duì)表單的驗(yàn)證的服務(wù)，這是webx中一個(gè)極其重要的服務(wù)，將驗(yàn)證邏輯和表現(xiàn)邏輯分離。

在form.xml中詳細(xì)的定義了表單驗(yàn)證的要求，并定義了相應(yīng)驗(yàn)證模塊Group。

將form.xml中定義的group在頁(yè)面模板中創(chuàng)建出其實(shí)例。

在用戶填寫完表單進(jìn)行提交操作的時(shí)候需要在Action中注入FromService的實(shí)例，并通過(guò)fromService對(duì)表單進(jìn)行驗(yàn)證。

以上是一個(gè)簡(jiǎn)單的form service的使用場(chǎng)景，對(duì)于form service還有一些更加深層次的應(yīng)用。比如國(guó)際化之類的使用。form service很好的解決了表單驗(yàn)證的代碼冗雜問(wèn)題，在表單的驗(yàn)證方面是一個(gè)很好的服務(wù)。

URIBroker Service的作用是對(duì)于應(yīng)用中的URI進(jìn)行統(tǒng)一的管理，比如由AnalyzeURLValve來(lái)分析請(qǐng)求URL，還可以動(dòng)態(tài)的生成URI，而擁有以下的好處：

? 集中管理 —— 全網(wǎng)站的URL均可在同一個(gè)配置文件中管理

? 可靠 —— 動(dòng)態(tài)生成，不容易出錯(cuò)

? 規(guī)范 —— 例如在生成query string時(shí)，會(huì)自動(dòng)URL encoding

? 透明 —— 應(yīng)用程序、模板不需要知道最終生成的URL的樣子，修改URL就變得很簡(jiǎn)單

URI的用法如下：

• 取得URIBrokerService：

URIBrokerServiceuriBrokerService = (URIBrokerService)
getWebxComponent()
getService(URIBrokerService.SERVICE_NAME);

• 取得指定名稱的URIBroker：

URIBrokeruriBroker = uriBrokerService.getURIBroker(
"petstoreLoginLink", rundata);

• 渲染URL：

Stringurl = uriBroker.render();

對(duì)于前臺(tái)的顯示，使用了Velocity渲染技術(shù)，將頁(yè)面靜態(tài)設(shè)計(jì)和頁(yè)面的動(dòng)態(tài)數(shù)據(jù)呈現(xiàn)分離，通過(guò)模板技術(shù)和pull技術(shù)使得界面可以先于程序優(yōu)先設(shè)計(jì)，并且將這兩個(gè)方面脫離使得維護(hù)的成本降低。

模板方面如下：由layout，control和screen組成。而相應(yīng)的Java代碼中由screen，control和action組成。

對(duì)于頁(yè)面的渲染過(guò)程如下：

從上面這個(gè)數(shù)據(jù)流來(lái)看，用戶首先通過(guò)對(duì)于view的操作將http request發(fā)送到服務(wù)器，在服務(wù)器端首先要進(jìn)行一系列的處理，比如Request Context Service對(duì)http request的處理，Pipeline service對(duì)流程的處理等等，以上這些處理都可以放在WebxController層里。

經(jīng)過(guò)webxController的這些處理以后調(diào)用兩個(gè)方面，一個(gè)是screen進(jìn)行渲染，另一個(gè)是調(diào)用action進(jìn)行請(qǐng)求的處理。如果是screen進(jìn)行渲染，則使用Template Service將頁(yè)面渲染呈現(xiàn)出來(lái)。如果是調(diào)用action進(jìn)行請(qǐng)求處理，則需要在action中繼續(xù)調(diào)用AO來(lái)進(jìn)行后臺(tái)的處理，在調(diào)用AO的時(shí)候使用Command模式。AO繼續(xù)調(diào)用Biz層，將處理交給業(yè)務(wù)邏輯，業(yè)務(wù)邏輯在調(diào)用數(shù)據(jù)持久化層，即DAO進(jìn)行數(shù)據(jù)訪問(wèn)。

整個(gè)流程如上圖所示，從最前面到最后面，再依次返回。Webx最具特點(diǎn)的是其WebxController層，其中包含了上面所講的眾多service，通過(guò)這些service對(duì)應(yīng)用進(jìn)行整體的控制，而到后面的業(yè)務(wù)邏輯層以后，就和大多數(shù)J2EE框架類似了。

說(shuō)一下對(duì)于整個(gè)webx框架學(xué)習(xí)后的感受吧。

首先，webx框架是一個(gè)比較重量級(jí)的企業(yè)級(jí)JavaEE應(yīng)用框架。說(shuō)其重量級(jí)，是指使用webx的整體功能。當(dāng)然如果像一開始說(shuō)的那樣，僅使用其SpringEx層次的部分，則沒有這么龐大。當(dāng)然在淘寶和阿里巴巴里，大多數(shù)web項(xiàng)目使用的是就是整個(gè)webx的框架。對(duì)于這樣一個(gè)重量級(jí)的框架，有人說(shuō)它臃腫，對(duì)，確實(shí)是臃腫，但這卻是必須的。

我覺得，一個(gè)企業(yè)級(jí)的應(yīng)用和一個(gè)簡(jiǎn)單應(yīng)用相比，最大的差別是對(duì)于代碼的維護(hù)方式是不同的。企業(yè)級(jí)應(yīng)用中，對(duì)于一個(gè)項(xiàng)目往往需要好多人來(lái)共同維護(hù)，或者說(shuō)在項(xiàng)目重構(gòu)的時(shí)候的開發(fā)人員和上一版本的開發(fā)人員很有可能沒有交集。這樣，如何去讀懂前人的代碼，如何去修改其他人的代碼則成了一個(gè)比較嚴(yán)重的問(wèn)題。

而從另一方面來(lái)看，一個(gè)重量級(jí)框架和輕量級(jí)框架相比，最大的差別是在于功能實(shí)現(xiàn)以及層次劃分和模塊獨(dú)立方面是不同的。一個(gè)重量級(jí)框架擁有著各種服務(wù)代碼(即service)，很多東西都不需要進(jìn)行編寫，直接在配置文件中加載服務(wù)即可實(shí)現(xiàn)功能。另一方面來(lái)說(shuō)，一個(gè)重量級(jí)框架是層次清晰的，各個(gè)層次的耦合度比較低，模塊和模塊之間相對(duì)比較獨(dú)立。

這樣，對(duì)于一個(gè)企業(yè)級(jí)的應(yīng)用來(lái)說(shuō)，是需要一個(gè)重量級(jí)框架的。雖然對(duì)于重量級(jí)框架的學(xué)習(xí)成本比較高，但是一旦新人深入學(xué)習(xí)了框架的內(nèi)容，則可以在很多情況下方便的使用框架來(lái)組織自己的應(yīng)用。通過(guò)對(duì)已有的Service的調(diào)用，使得所有開發(fā)人員在該Service的功能的實(shí)現(xiàn)方面不需要自己進(jìn)行代碼編寫，從而保持代碼的標(biāo)準(zhǔn)化和統(tǒng)一性。這樣，一是提高了開發(fā)人員在閱讀已有代碼時(shí)的效率。二是提高了開發(fā)人員編寫代碼，組織應(yīng)用的效率。三則是通過(guò)減少新開發(fā)代碼的代碼量，降低了Debug發(fā)生的概率，使得穩(wěn)定性上升。

總的來(lái)說(shuō)，一個(gè)重量級(jí)的框架雖然看上去臃腫，卻很合適這種開發(fā)人員眾多的企業(yè)級(jí)應(yīng)用。

WebX相比于很多其他的JavaEE框架，比較明顯的特點(diǎn)在于其的定制和擴(kuò)展特性。WebX的核心是Spring容器，其他幾乎所有的功能都是通過(guò)Service的方式來(lái)完成的。而每個(gè)Service實(shí)際上就是在Spring容器中的一個(gè)個(gè)Service Bean。這些Service是多可少的，全憑在配置文件中配置。這樣，每一個(gè)應(yīng)用就可以選取與自身相關(guān)的Service進(jìn)行使用，對(duì)于不需要的Service完全可以不予加載。這就使得應(yīng)用可以根據(jù)需要定制自身的Service群。另一方面，隨著技術(shù)的日益發(fā)展，很多舊的功能都需要淘汰，而很多新的功能需要加入。通過(guò)WebX的Service機(jī)制，可以很好的做到這一點(diǎn)。所有的Service就好象插件一樣，對(duì)于不需要的舊的Service可以進(jìn)行去除，而對(duì)于新的好的Service可以給予加入。這樣就很好的擴(kuò)展了現(xiàn)有的結(jié)構(gòu)，使得webx框架不斷進(jìn)步。

學(xué)習(xí)開源框架WebX的總結(jié)