SimpleFramewok基于后處理模式與傳統B/S開發模式的總結

原文： http://simpleframework.net/

本文對Java B/S開發模式做一個總結，對JSP+JDBC、JSP+JavaBean以及基于MVC Framework等Java B/S開發模式的發展做一些回顧和思考，從而更好的理解和使用SimpleFramework.

B/S作為如今最為流行的體系結構模式，也是受到了廣大開發人員以及客戶的認同，其開發模式也在不斷的發展著，在這里主要就Java B/S的開發模式做一番回顧和探討，也算是自己對于Java B/S開發模式的一種總結。

JSP+JDBC

在Java B/S開發模式中最簡單的一種開發模式是頁面+邏輯處理，映射到技術上反應出來的有Jsp+Jdbc，在基于這類的實現中在View層也就是jsp頁面上 負責數據的顯示、邏輯處理，結合jdbc完成數據的持久化，在小型的項目中，人們確實發現這種方式是最為方便的，但在復雜的項目以及需求不斷變化的項目 中，人們慢慢的發現這種方式造成了不少的問題， 首先是調試的問題，想想在一個jsp頁面中進行排錯是多么的困難，其次是修改的問題，為了滿足用戶需求的一個小小的變化，都需要去改不少的頁面，而且很多

時候由于寫的時間長了，自己都需要回憶很久才能想起是怎么回事，更不用說如果人員流動了會怎么樣，同時還帶來開發效率的問題，由于需要缺少足夠的調試的支

持，需要較為熟練的開發人員才能快速的完成，對于一般的人員來說需要一定的適應和學習過程，當然伴隨而來的還有諸如修改界面的時候一不小心少copy了點 代碼什么造成的錯，最大的問題可能還是重用的問題，通常會造成N多同樣的代碼在頁面上copy來copy去的，總結下來在這種模式下有幾個比較重大的問題 就是：</p>

1、調試問題。

2、維護問題，顯示和邏輯處理在一起導致了修改顯示的時候較為困難，至于修改代碼則因為之前的調試問題導致了困難，同時由于邏輯均在頁面上后期接手人員需要一段時間去理解。

3、代碼重用性問題。

但同樣它還是存在優點的，那就是可以很快的上手，但由于調試和維護性問題確實太大了，所以在現在也是基本不再采用這種方式了。

JSP+JavaBean

在經歷了jsp+jdbc階段后，開始考慮怎么樣去解決上面三個問題，這個時候就誕生了諸JSP+JavaBean這樣的技術體系，在這個體系中由 jsp頁面負責顯示以及接收頁面請求，并調用相應的JavaBean來完成邏輯處理，在獲取其返回的處理數據后轉到相應的頁面進行顯示。在這樣的技術體系 中，由于邏輯是由JavaBean來完成的，可以對其進行調試了，代碼的重用性一定程度上也得到了提高。剛開始的時候用這樣的技術體系確實發現比以前用 jsp+jdbc爽了很多，但隨著用多了，慢慢又發現了問題，那就是在頁面中需要編寫對于頁面請求數據的獲取，還得根據請求去調用相應的 javabean，并根據javabean的處理結果轉入相應的頁面，這同樣造成了修改的麻煩，畢竟是去頁面上修改這些邏輯，總結下來在這種Java B/S開發模式下有比較重大的問題就是：

1、代碼重用性以及維護性問題。但這里的代碼重用性問題和jsp+jdbc的就不同，在邏輯處理部分現在已經可以重用了，但現在在各個頁面就不得不 重復的寫獲取頁面請求的參數、相應的調用Model、根據Model的處理結果轉發頁面，這樣的話就導致了在改的時候需要到處去找，造成了維護的復雜。

2、系統結構不清晰。畢竟仍然是在頁面控制整個響應頁面事件的處理流程，這個時候就造成了很多頁面中出現完全相同的jsp代碼，而且控制代碼在頁 面，仍然是不便操作，例如對于JavaBean的調用等，而且由于獲取javabean的數據需要轉發的緣故，其實通常就是在最終的顯示頁面上加上上面的 控制事件處理流程的代碼，并沒有真正的做到顯示和處理的分離。

同樣，它的優點在于分離了顯示和業務邏輯處理，增強了可調試以及維護性，而且也是很容易上手的，對于小型項目來說仍然是可選的方案之一。

基于MVC Framework

在經歷了上面的Jsp+JavaBean的Java B/S開發模式后，我們發現其實現在最需要的就是在jsp、javabean之間能有個東西自動完成頁面請求數據的封裝、根據請求調用相應的 javabean、同時根據javabean的處理結果返回至相應的View，有了這樣的思想后，發現smalltalk中的MVC思想很適合這種場景， 于是便在Java B/S開發中引入了MVC思想，在這里也簡單的介紹下MVC思想，MVC強調View和Model的分離，View所面對的是Controller，由 Controller負責與Model進行交互，View只負責顯示頁面以及顯示邏輯的處理，顯示邏輯指的是諸如第一行要顯示藍色、第二行要顯示紅色這樣

的顯示方面的處理，Controller負責接受頁面請求，并將其請求數據進行封裝，同時根據請求調用相應的Model進行邏輯處理，在Model處理后

返回結果數據到Controller，Controller將根據此數據調用相應的View，并將此數據傳遞給View，由View負責將數據進行融合并 最終展現。MVC帶來的優點很明顯的體現出來了，基于一個這樣的MVC Framework的話開發人員可以按照一種固定的模式進行開發，規范了整個開發過程，提高了質量以及系統結構的清晰性，并由于保證了 View/Model的分離，使得一個Model可以對于多種顯示形式的View，需要的僅僅是去改變View和Controller。</p>

按照MVC思想，最容易想到的實現方案莫過于jsp+servlet+javabean，在這里面jsp對應著View，servlet對應著 Controller，javabean對應著Model，因為采用servlet可使用servlet container已經封裝好的頁面數據請求對象HttpServletRequest，這樣就省去了自己封裝頁面請求數據的工作，作為 Controller同時還需要承擔根據請求調用對應的javabean，最簡單的做法無非就是在Servlet中直接根據某種邏輯(諸如反射或接口)調 用相應的bean進行執行，之后將HttpServletRequest、HttpServletResponse作為參數傳入javabean進行處

理，javabean從HttpServletRequest中獲取請求數據，將返回的結果數據放入HttpServletResponse，整個過程結

束后繼續由Controller接手進行處理，這個時候作為Controller的servlet將根據處理的結果返回相應的頁面，在這個模型使用時人們

慢慢的發現了一個問題，那就是隨著jsp、javabean的變化造成了controller的不斷修改，需要修改其中調用相應javabean以及轉發 相應頁面的部分，為了解決這個問題，首先想到的是應該分離根據請求調用相應javabean的步驟，這個時候采用了設計模式中的front controller+application controller的方法，front controller負責接受頁面請求并進行封裝，同時將此數據對象傳遞至application controller，由application controller來負責調用相應的bean，這樣的設計其實都是遵循著一個設計原則，就是職責單一，通常實現application controller的模式是Command模式，在這種情況下MVC Framework的結構體系就演變成了view+controller(front+application)+model。</p>

在完成了上述演變后慢慢又發現了一個問題，就是model依賴于了httpservletrequest，這樣造成的一個問題就是沒法測試，仍然要 不斷重啟服務器來測試，當然與此同時的發展是model層的細化，細化成用于響應頁面請求的action Layer+Domain Model Layer+Persistent Layer，在這里不去討論后面層次的問題，因為作為MVC Framework它并不管你Model層是怎么個處理流程的。

慢慢也發現了另外一個問題，那就是變化經常要影響到controller的修改，于是便引入了采用配置文件的解決方法，編寫action的配置文 件，在配置文件中控制根據action的返回結果轉入相應的View，這樣的話在將來需要改變的時候只需要去改變這個配置文件就可以了，保證了 Controller的穩定，這是典型的設計中的重點考慮因素，分離變化和不變化的，讓變化造成的影響最小。

但在引入了上面的配置文件后，慢慢又發現了問題，那就是手寫配置文件總是容易出各種各樣的問題，這個時候采用圖形化的界面來生成配置文件的想法又有了，這也就造就了page flow的誕生，當然，這只是page flow的一小部分功能。

當然，隨著MVC的發展，也帶動了其他相關技術的發展，如異步請求/響應模式(ajax、amowa)等。

在MVC思想接受后開源界的MVC Framework也是如雨后春筍般的冒出，比較知名的有struts、webwork、spring mvc等，這些MVC Framework基本都已經做到了上面提及的MVC思想演變的一些需求，當然，即使現在的MVC Framework是做到了，但在Java B/S開發模式使用這些MVC Framework的時候我們通常又開始違背MVC思想的基本要素，就是保持View僅僅是View的原則，所以我比較推薦在View使用 Velocity這之類的東西作為View，盡量保持View的純潔性，任何技術的發展都是循序漸進的，不站在那個高度的時候是不知道前面還有什么樣的高 山的.那么現在我們缺少的又是什么呢？現在的MVC Framework中還存在著什么不足呢？這個問題是值得大家共同思考的。

基于SimpleFramework

 

SimpleFramework的誕生也正是基于這樣的理由： 構造符合標準的 Web 框架，用組合化配置化方式解決Web 應用問題 。

Web應用中，無論服務器端采用（Java EE/.NET），客戶端的請求經Web或應用服務器解析后，最終返回客戶端的響應內容主體都是HTML（含Javascript/CSS等）。由此，解 決問題的契機就是在響應返回客戶端（/瀏覽器）之前，“攔截”響應，解析其中HTML，并進行“再處理”，此即“后處理”應用模式。其實現方案可有服務器 端（過濾/攔截器等）和客戶端（插件等）兩種。在Java EE體系下，支持Servlet 2.3的各種應用服務器（Weblogic/Websphere/JBoss/Tomca等）都有“過濾器（Filter/Interceptor）”機 制，恰好為本框架的實現奠定了技術基礎。

SimpleFramowk 實現了開放的組件體系，基于標準化的組件標準可以所需增加業務相關的組件,快速的提供針對應用系統的基礎組件庫，業務組件庫，內容組件庫等，這應該是目前Web框架的高端應用。

SimpleFramework貫穿始終的核心理念：組件應用，業務積累。

1）  業務組件化：應用或模塊級可復用的組件化封裝。

2）  可持續積累：應用資源及業務組件的可持續積累。

3）  組件化開發：開箱即用和全程覆蓋的配置化組件。

4）  HTTP原生態：保留HTML/HTTP及請求/響應的原生態。

5）  無碼AJAX應用：少用或不用Javascript的AJAX應用。

6）  資源繼承：對既有應用資源的有效整合及平滑遷移。

7）  有效補充：對現有Web框架或技術的非侵入式補充。

8）  開放架構：開放及隨需擴展的組件體系架構。

9）  無縫兼容：對現有Web及新技術的無縫兼容。

10）  簡單實用：支持一體化Web應用開發過程。

了解處理流程將有利于有效地使用本框架，其中包含如下步驟：

      （1）      攔截響應中HTML。

      （2）      組件XML元數據解析。

（3）      業務Handle類執行。

（4）     組件代碼生成及渲染。

（5）     復合HTML生成及響應。