B/S 作為如今最為流行的體系結構模式，也是受到了廣大開發人員以及客戶的認同，其開發模式也在不斷的發展著，在這裡主要就 Java B/S 的開發模式做一番回顧和探討，也算是自己對於 Java B/S 開發模式的一種總結。
JSP+Jdbc
在 B/S 開發中最簡單的一種開發模式是頁面 + 邏輯處理，映射到技術上反應出來的有 Jsp+Jdbc ，在基於這類的實現中在 VIEw 層也就是 JSp 頁面上負責數據的顯示、邏輯處理，結合 jdbc 完成數據的持久化，在小型的項目中，人們確實發現這種方式是最為方便的，但在復雜的項目以及需求不斷變化的項目中，人們慢慢的發現這種方式造成了不少的問題，首先是調試的問題，想想在一個 JSP 頁面中進行排錯是多麼的困難，其次是修改的問題，為了滿足用戶需求的一個小小的變化，都需要去改不少的頁面，而且很多時候由於寫的時間長了，自己都需要回憶很久才能想起是怎麼回事，更不用說如果人員流動了會怎麼樣，同時還帶來開發效率的問題，由於需要缺少足夠的調試的支持，需要較為熟練的開發人員才能快速的完成，對於一般的人員來說需要一定的適應和學習過程，當然伴隨而來的還有諸如修改界面的時候一不小心少 copy 了點代碼什麼造成的錯，最大的問題可能還是重用的問題，通常會造成 N 多同樣的代碼在頁面上 copy 來 copy 去的，總結下來在這種模式下有幾個比較重大的問題就是:
1、 調試問題。
2、 維護問題，顯示和邏輯處理在一起導致了修改顯示的時候較為困難，至於修改代碼則因為之前的調試問題導致了困難，同時由於邏輯均在頁面上後期接手人員需要一段時間去理解。
3、 代碼重用性問題。
但同樣它還是存在優點的，那就是可以很快的上手，但由於調試和維護性問題確實太大了，所以在現在也是基本不再采用這種方式了。
JSP+JavaBean
在經歷了 jsp+jdbc 階段後，開始考慮怎麼樣去解決上面三個問題，這個時候就誕生了諸 JSP+JavaBean 這樣的技術體系，在這個體系中由 JSp 頁面負責顯示以及接收頁面請求，並調用相應的 JavaBean 來完成邏輯處理，在獲取其返回的處理數據後轉到相應的頁面進行顯示。在這樣的技術體系中，由於邏輯是由 JavaBean 來完成的，可以對其進行調試了，代碼的重用性一定程度上也得到了提高。剛開始的時候用這樣的技術體系確實發現比以前用 JSP+jdbc 爽了很多，但隨著用多了，慢慢又發現了問題，那就是在頁面中需要編寫對於頁面請求數據的獲取，還得根據請求去調用相應的 javabean ，並根據 Javabean 的處理結果轉入相應的頁面，這同樣造成了修改的麻煩，畢竟是去頁面上修改這些邏輯，總結下來在這種模式下有比較重大的問題就是:
1、 代碼重用性以及維護性問題。但這裡的代碼重用性問題和 JSP+jdbc 的就不同，在邏輯處理部分現在已經可以重用了，但現在在各個頁面就不得不重復的寫獲取頁面請求的參數、相應的調用 Model 、根據 Model 的處理結果轉發頁面，這樣的話就導致了在改的時候需要到處去找，造成了維護的復雜。
2、 系統結構不清晰。畢竟仍然是在頁面控制整個響應頁面事件的處理流程，這個時候就造成了很多頁面中出現完全相同的 JSP 代碼，而且控制代碼在頁面，仍然是不便操作，例如對於 JavaBean 的調用等，而且由於獲取 Javabean 的數據需要轉發的緣故，其實通常就是在最終的顯示頁面上加上上面的控制事件處理流程的代碼，並沒有真正的做到顯示和處理的分離。
同樣，它的優點在於分離了顯示和業務邏輯處理，增強了可調試以及維護性，而且也是很容易上手的，對於小型項目來說仍然是可選的方案之一。
基於 MVC Framework
在經歷了上面的 JSp+JavaBean 後，我們發現其實現在最需要的就是在 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 。
按照 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 。
在完成了上述演變後慢慢又發現了一個問題，就是 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 是做到了，但在使用這些 MVC Framework 的時候我們通常又開始違背 MVC 思想的基本要素，就是保持 View 僅僅是 View 的原則，所以我比較推薦在 View 使用 Velocity 這之類的東西作為 View ，盡量保持 VIEw 的純潔性，任何技術的發展都是循序漸進的，不站在那個高度的時候是不知道前面還有什麼樣的高山的，那麼現在我們缺少的又是什麼呢?現在的 MVC Framework 中還存在著什麼不足呢?這是值得我們思考的。
