dorado技術園地

          與您共同討論dorado技術及其應用技巧

            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
            8 隨筆 :: 0 文章 :: 37 評論 :: 1 Trackbacks

          要了解dorado的詳情請瀏覽http://www.bstek.com

          http://www.aygfsteel.com/dorado/archive/2005/07/25/8367.html
          中我們已經了解到
          dorado的開發模式與傳統的基于MVC的企業應用開發模式之間存在著一些差異. 可能看到這里您已經產生了一大堆的問題:

          l         為什么一定要有這樣的差異存在?

          l         這種差異將在多大的程度上影響我們企業原有的系統或開發框架(開發規范)?

          l         這種差異將在多大的程度上影響程序員原有的編程習慣?

          l         Dorado的開發方式是否擁有足夠的健壯性、足夠的擴展性?

          為了深入的解答上述這些問題, 我們首先來了解一下傳統的MVC開發模式. 如下圖(此處的Control以目前最為流行的Struts為例):

          mvc.gif
          圖表
          傳統的基于MVC架構開發模式

          1.       Request(請求) Client(瀏覽器)發起請求時, 改請求將首先被控制層(StrutsAction)接受.

          2.       Dispatch(分發): Action將調用具體的Model中的BO對象來完成實際的業務邏輯操作, 然后將執行結果存貯于RequestAttributies. (一般慣例是這樣的)

          3.       Forward(轉向): 商業邏輯執行完成后Action將根據商業邏輯的執行結果將Request轉向給具體的視圖(JSP).

          4.       Extract(提取): 一般而言JSP不會去直接訪問Model, 而是直接到RequestAttributies中提取已經在第2歩存放好的業務數據.

          5.       Response(反饋): 視圖的Server端準備工作完成后會自動將各種信息輸出到Response對象中反饋給Client.

          從上面的分析我們不難看到在這種開發模式中, 業務邏輯主要都是在Action中完成調用的, 然后通過RequestAttributies作為上下文對象在ActionJSP之間傳遞信息.

          那么基于dorado的開發是否也可以按照這種方式來操作呢? 答案是可以, 但是dorado中某些高級功能會受到一些影響.

          因為在傳統的B/S應用中, ClientServer端的交互完全是通過HTML FORM來完成. 而且每次執行完一個業務邏輯操作之后往往會刷新整個Client頁面, 即連同操作結果和HTML一起下載并重新裝載整個Client頁面. 可是在doradoClient中我們可以實現很多類似頁面局部刷新、數據分批下載、遠程方法調用、復雜數據對象的整體提交這樣的功能. 這些功能的實現不能完全依賴于傳統的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, 我們應當把這種請求的業務邏輯調用放到doradoModule或著ViewModel, dorado來幫我們完成繁瑣的XML信息處理, 我們只要直接使用通過解析獲得的Java對象型的數據就可以了.

          那么這種方式是否意味著原本集中在Action中的業務邏輯調用被分散到了幾個不同的環節, 造成系統中業務邏輯的分散而不易管理呢? 應該說只要我們對系統稍作調整就可以避免這個問題的出現了 – 我們需要引入業務代表層(BO Delegate).

          struts-action.gif
          圖表
          原有的系統調用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對象. 

          dorado-action.gif
          圖表
          改造后系統調用BO的模式

          如上圖所示, Action接到XMLHTTP發送的請求時會將處理轉交給dorado中的ModuleViewModel對象來處理, 由他們首先來完成對XML提交信息的解析. 而后再利用BO Delegate將這些信息組裝成BO所需要的VO對象. 這樣, 我們事實上幾乎不需要對BO層做什么改動就可以將dorado導入到系統中了. 而且很明顯這樣的調整是不會影響到整個系統的擴展性的.

          從另外一個簡單的角度來看這個問題, 事實上就是在新的系統架構中我們保留整個Model層的設計, dorado來替換原先的View. 然后在Model層和doradoView層直接通過一組特別定義的交互接口來實現對接. 對接時使用VO作為數據交換對象. 同時dorado又特別提供了DODatasetDOUtils等對象和工具類可以輔助我們更加方便的構造和溶解各種類型的VO對象. 因此你大可不必為整合dorado而大傷腦筋, 盡管他需要我們適當的調整原有的開發習慣, 但是dorado帶給我們的其它好處是顯而易見的.

           

          posted on 2005-07-19 17:13 dorado技術園地 閱讀(2732) 評論(0)  編輯  收藏

          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 会昌县| 沂南县| 雅安市| 甘南县| 翼城县| 达拉特旗| 田阳县| 阜新| 股票| 玉田县| 延边| 邻水| 义乌市| 庐江县| 屯门区| 弥勒县| 大余县| 长治县| 叶城县| 连平县| 双城市| 河北区| 利津县| 平乡县| 进贤县| 永济市| 长垣县| 普安县| 香港 | 荆门市| 聂荣县| 寻乌县| 项城市| 当雄县| 康乐县| 尚义县| 巴楚县| 曲松县| 莲花县| 霍林郭勒市| 长兴县|