要了解dorado的詳情請瀏覽http://www.bstek.com
在http://www.tkk7.com/dorado/archive/2005/07/25/8367.html中我們已經了解到dorado的開發模式與傳統的基于MVC的企業應用開發模式之間存在著一些差異. 可能看到這里您已經產生了一大堆的問題:
l 為什么一定要有這樣的差異存在?
l 這種差異將在多大的程度上影響我們企業原有的系統或開發框架(開發規范)?
l 這種差異將在多大的程度上影響程序員原有的編程習慣?
l Dorado的開發方式是否擁有足夠的健壯性、足夠的擴展性?
為了深入的解答上述這些問題, 我們首先來了解一下傳統的MVC開發模式. 如下圖(此處的Control以目前最為流行的Struts為例):
圖表 傳統的基于MVC架構開發模式
1. Request(請求)： 當Client端(瀏覽器)發起請求時, 改請求將首先被控制層(Struts的Action)接受.
2. Dispatch(分發): Action將調用具體的Model中的BO對象來完成實際的業務邏輯操作, 然后將執行結果存貯于Request的Attributies中. (一般慣例是這樣的)
3. Forward(轉向): 商業邏輯執行完成后Action將根據商業邏輯的執行結果將Request轉向給具體的視圖(JSP).
4. Extract(提取): 一般而言JSP不會去直接訪問Model層, 而是直接到Request的Attributies中提取已經在第2歩存放好的業務數據.
5. Response(反饋): 視圖的Server端準備工作完成后會自動將各種信息輸出到Response對象中反饋給Client端.
從上面的分析我們不難看到在這種開發模式中, 業務邏輯主要都是在Action中完成調用的, 然后通過Request的Attributies作為上下文對象在Action和JSP之間傳遞信息.
那么基于dorado的開發是否也可以按照這種方式來操作呢? 答案是可以, 但是dorado中某些高級功能會受到一些影響.
因為在傳統的B/S應用中, Client與Server端的交互完全是通過HTML FORM來完成. 而且每次執行完一個業務邏輯操作之后往往會刷新整個Client頁面, 即連同操作結果和HTML一起下載并重新裝載整個Client頁面. 可是在dorado的Client中我們可以實現很多類似頁面局部刷新、數據分批下載、遠程方法調用、復雜數據對象的整體提交這樣的功能. 這些功能的實現不能完全依賴于傳統的HTML FORM的提交來完成, 而是需要依靠瀏覽器的XMLHTTP技術.
|
提示 |
上面提到的dorado中的頁面局部刷新、數據分批下載、遠程方法調用、復雜數據對象的整體提交等功能您可以通過dorado的SampleCenter中的下面一個例子來體驗.
|
綜上, 對于Server端的程序而言傳統的B/S應用和dorado應用最大的差別就在于此.
l 在傳統的B/S應用中Server端的程序只需要處理一種Client請求, 即執行邏輯然后返回視圖, 且要處理的Client請求的參數類型都是類同的.
l 在dorado應用中Server端的程序需要處理至少兩種Client請求. 其中一種是簡單的類似傳統B/S應用的請求, 另一種是dorado獨具的用于處理類似數據分批下載和復雜數據提交的請求, 這一類請求都是通過XMLHTTP技術提交的, 其參數信息都包含在一段XML中. 且這一類請求的反饋結果必須同樣是XML格式的, 其中只包含數據和執行結果, 不能包含HTML信息.
這樣一來我們便很難將所有的請求的處理代碼一概放到Action中完成. 因為對于dorado應用, 其中的部分請求的參數是相對比較復雜的XML. 所以為了避免自己手工的去解析和組裝XML, 我們應當把這種請求的業務邏輯調用放到dorado的Module或著ViewModel中, 讓dorado來幫我們完成繁瑣的XML信息處理, 我們只要直接使用通過解析獲得的Java對象型的數據就可以了.
那么這種方式是否意味著原本集中在Action中的業務邏輯調用被分散到了幾個不同的環節, 造成系統中業務邏輯的分散而不易管理呢? 應該說只要我們對系統稍作調整就可以避免這個問題的出現了 – 我們需要引入業務代表層(BO Delegate).
圖表 原有的系統調用BO的模式
如上圖所示, 在原有的系統中我們一般首先會在Action中將Request中附帶的Parameter等信息提供給BO Delegate, 由BO Delegate將其組裝成一個或幾個VO(Value Object)對象, 或者直接使用Struts提供的FormBean對象作為VO對象. 然后再利用這些VO對象去調用自己的業務邏輯對象. 對于BO而言, 他的前端介面就是VO.
|
注意 |
在您的系統有可能并沒有明確的定義BO Delegate這種對象, 可它事實上往往是存在的. 除非您的系統中直接將Request對象傳進了BO層. 如果是這樣的話, 我們認為你的系統原本也屬于應進行重構的范疇. 因為這樣的BO層與Request進行了不必要的耦合, 大大降低了系統的可擴展性. 且這樣的BO是無法支持單元測試(測試驅動開發的)的. |
對于dorado應用而言BO仍可以以完全相同的VO作為其前端介面, 只是我們需要另外一種或幾種BO Delegate負責將不同的外部數據構造成統一的VO對象.
圖表 改造后系統調用BO的模式
如上圖所示, 當Action接到XMLHTTP發送的請求時會將處理轉交給dorado中的Module或ViewModel對象來處理, 由他們首先來完成對XML提交信息的解析. 而后再利用BO Delegate將這些信息組裝成BO所需要的VO對象. 這樣, 我們事實上幾乎不需要對BO層做什么改動就可以將dorado導入到系統中了. 而且很明顯這樣的調整是不會影響到整個系統的擴展性的.
從另外一個簡單的角度來看這個問題, 事實上就是在新的系統架構中我們保留整個Model層的設計, 用dorado來替換原先的View層. 然后在Model層和dorado的View層直接通過一組特別定義的交互接口來實現對接. 對接時使用VO作為數據交換對象. 同時dorado又特別提供了DODataset和DOUtils等對象和工具類可以輔助我們更加方便的構造和溶解各種類型的VO對象. 因此你大可不必為整合dorado而大傷腦筋, 盡管他需要我們適當的調整原有的開發習慣, 但是dorado帶給我們的其它好處是顯而易見的.