B/S 作為如今最為流行的體系結(jié)構(gòu)模式，也是受到了廣大開(kāi)發(fā)人員以及客戶(hù)的認(rèn)同，其開(kāi)發(fā)模式也在不斷的發(fā)展著，在這里主要就 Java B/S 的開(kāi)發(fā)模式做一番回顧和探討，也算是自己對(duì)于 Java B/S 開(kāi)發(fā)模式的一種總結(jié)。

　　Jsp+Jdbc

　　在 B/S 開(kāi)發(fā)中最簡(jiǎn)單的一種開(kāi)發(fā)模式是頁(yè)面 + 邏輯處理，映射到技術(shù)上反應(yīng)出來(lái)的有 Jsp+Jdbc ，在基于這類(lèi)的實(shí)現(xiàn)中在 View 層也就是 jsp 頁(yè)面上負(fù)責(zé)數(shù)據(jù)的顯示、邏輯處理，結(jié)合 jdbc 完成數(shù)據(jù)的持久化，在小型的項(xiàng)目中，人們確實(shí)發(fā)現(xiàn)這種方式是最為方便的，但在復(fù)雜的項(xiàng)目以及需求不斷變化的項(xiàng)目中，人們慢慢的發(fā)現(xiàn)這種方式造成了不少的問(wèn)題，首先是調(diào)試的問(wèn)題，想想在一個(gè) jsp 頁(yè)面中進(jìn)行排錯(cuò)是多么的困難，其次是修改的問(wèn)題，為了滿(mǎn)足用戶(hù)需求的一個(gè)小小的變化，都需要去改不少的頁(yè)面，而且很多時(shí)候由于寫(xiě)的時(shí)間長(zhǎng)了，自己都需要回憶很久才能想起是怎么回事，更不用說(shuō)如果人員流動(dòng)了會(huì)怎么樣，同時(shí)還帶來(lái)開(kāi)發(fā)效率的問(wèn)題，由于需要缺少足夠的調(diào)試的支持，需要較為熟練的開(kāi)發(fā)人員才能快速的完成，對(duì)于一般的人員來(lái)說(shuō)需要一定的適應(yīng)和學(xué)習(xí)過(guò)程，當(dāng)然伴隨而來(lái)的還有諸如修改界面的時(shí)候一不小心少 copy 了點(diǎn)代碼什么造成的錯(cuò)，最大的問(wèn)題可能還是重用的問(wèn)題，通常會(huì)造成 N 多同樣的代碼在頁(yè)面上 copy 來(lái) copy 去的，總結(jié)下來(lái)在這種模式下有幾個(gè)比較重大的問(wèn)題就是:

　　1、 調(diào)試問(wèn)題。

　　2、 維護(hù)問(wèn)題，顯示和邏輯處理在一起導(dǎo)致了修改顯示的時(shí)候較為困難，至于修改代碼則因?yàn)橹暗恼{(diào)試問(wèn)題導(dǎo)致了困難，同時(shí)由于邏輯均在頁(yè)面上后期接手人員需要一段時(shí)間去理解。

　　3、 代碼重用性問(wèn)題。

　　但同樣它還是存在優(yōu)點(diǎn)的，那就是可以很快的上手，但由于調(diào)試和維護(hù)性問(wèn)題確實(shí)太大了，所以在現(xiàn)在也是基本不再采用這種方式了。

　　Jsp+JavaBean

　　在經(jīng)歷了 jsp+jdbc 階段后，開(kāi)始考慮怎么樣去解決上面三個(gè)問(wèn)題，這個(gè)時(shí)候就誕生了諸 JSP+JavaBean 這樣的技術(shù)體系，在這個(gè)體系中由 jsp 頁(yè)面負(fù)責(zé)顯示以及接收頁(yè)面請(qǐng)求，并調(diào)用相應(yīng)的 JavaBean 來(lái)完成邏輯處理，在獲取其返回的處理數(shù)據(jù)后轉(zhuǎn)到相應(yīng)的頁(yè)面進(jìn)行顯示。在這樣的技術(shù)體系中，由于邏輯是由 JavaBean 來(lái)完成的，可以對(duì)其進(jìn)行調(diào)試了，代碼的重用性一定程度上也得到了提高。剛開(kāi)始的時(shí)候用這樣的技術(shù)體系確實(shí)發(fā)現(xiàn)比以前用 jsp+jdbc 爽了很多，但隨著用多了，慢慢又發(fā)現(xiàn)了問(wèn)題，那就是在頁(yè)面中需要編寫(xiě)對(duì)于頁(yè)面請(qǐng)求數(shù)據(jù)的獲取，還得根據(jù)請(qǐng)求去調(diào)用相應(yīng)的 javabean ，并根據(jù) javabean 的處理結(jié)果轉(zhuǎn)入相應(yīng)的頁(yè)面，這同樣造成了修改的麻煩，畢竟是去頁(yè)面上修改這些邏輯，總結(jié)下來(lái)在這種模式下有比較重大的問(wèn)題就是:

　　1、 代碼重用性以及維護(hù)性問(wèn)題。但這里的代碼重用性問(wèn)題和 jsp+jdbc 的就不同，在邏輯處理部分現(xiàn)在已經(jīng)可以重用了，但現(xiàn)在在各個(gè)頁(yè)面就不得不重復(fù)的寫(xiě)獲取頁(yè)面請(qǐng)求的參數(shù)、相應(yīng)的調(diào)用 Model 、根據(jù) Model 的處理結(jié)果轉(zhuǎn)發(fā)頁(yè)面，這樣的話就導(dǎo)致了在改的時(shí)候需要到處去找，造成了維護(hù)的復(fù)雜。

　　2、 系統(tǒng)結(jié)構(gòu)不清晰。畢竟仍然是在頁(yè)面控制整個(gè)響應(yīng)頁(yè)面事件的處理流程，這個(gè)時(shí)候就造成了很多頁(yè)面中出現(xiàn)完全相同的 jsp 代碼，而且控制代碼在頁(yè)面，仍然是不便操作，例如對(duì)于 JavaBean 的調(diào)用等，而且由于獲取 javabean 的數(shù)據(jù)需要轉(zhuǎn)發(fā)的緣故，其實(shí)通常就是在最終的顯示頁(yè)面上加上上面的控制事件處理流程的代碼，并沒(méi)有真正的做到顯示和處理的分離。

　　同樣，它的優(yōu)點(diǎn)在于分離了顯示和業(yè)務(wù)邏輯處理，增強(qiáng)了可調(diào)試以及維護(hù)性，而且也是很容易上手的，對(duì)于小型項(xiàng)目來(lái)說(shuō)仍然是可選的方案之一。

　　基于 MVC Framework

　　在經(jīng)歷了上面的 Jsp+JavaBean 后，我們發(fā)現(xiàn)其實(shí)現(xiàn)在最需要的就是在 jsp 、 javabean 之間能有個(gè)東西自動(dòng)完成頁(yè)面請(qǐng)求數(shù)據(jù)的封裝、根據(jù)請(qǐng)求調(diào)用相應(yīng)的 javabean 、同時(shí)根據(jù) javabean 的處理結(jié)果返回至相應(yīng)的 View ，有了這樣的思想后，發(fā)現(xiàn) smalltalk 中的 MVC 思想很適合這種場(chǎng)景，于是便在 Java B/S 開(kāi)發(fā)中引入了 MVC 思想，在這里也簡(jiǎn)單的介紹下 MVC 思想， MVC 強(qiáng)調(diào) View 和 Model 的分離， View 所面對(duì)的是 Controller ，由 Controller 負(fù)責(zé)與 Model 進(jìn)行交互， View 只負(fù)責(zé)顯示頁(yè)面以及顯示邏輯的處理，顯示邏輯指的是諸如第一行要顯示藍(lán)色、第二行要顯示紅色這樣的顯示方面的處理， Controller 負(fù)責(zé)接受頁(yè)面請(qǐng)求，并將其請(qǐng)求數(shù)據(jù)進(jìn)行封裝，同時(shí)根據(jù)請(qǐng)求調(diào)用相應(yīng)的 Model 進(jìn)行邏輯處理，在 Model 處理后返回結(jié)果數(shù)據(jù)到 Controller ， Controller 將根據(jù)此數(shù)據(jù)調(diào)用相應(yīng)的 View ，并將此數(shù)據(jù)傳遞給 View ，由 View 負(fù)責(zé)將數(shù)據(jù)進(jìn)行融合并最終展現(xiàn)。 MVC 帶來(lái)的優(yōu)點(diǎn)很明顯的體現(xiàn)出來(lái)了，基于一個(gè)這樣的 MVC Framework 的話開(kāi)發(fā)人員可以按照一種固定的模式進(jìn)行開(kāi)發(fā)，規(guī)范了整個(gè)開(kāi)發(fā)過(guò)程，提高了質(zhì)量以及系統(tǒng)結(jié)構(gòu)的清晰性，并由于保證了 View/Model 的分離，使得一個(gè) Model 可以對(duì)于多種顯示形式的 View ，需要的僅僅是去改變 View 和 Controller 。

　　按照 MVC 思想，最容易想到的實(shí)現(xiàn)方案莫過(guò)于 jsp+servlet+javabean ，在這里面 jsp 對(duì)應(yīng)著 View ， servlet 對(duì)應(yīng)著 Controller ， javabean 對(duì)應(yīng)著 Model ，因?yàn)椴捎?servlet 可使用 servlet container 已經(jīng)封裝好的頁(yè)面數(shù)據(jù)請(qǐng)求對(duì)象 HttpServletRequest ，這樣就省去了自己封裝頁(yè)面請(qǐng)求數(shù)據(jù)的工作，作為 Controller 同時(shí)還需要承擔(dān)根據(jù)請(qǐng)求調(diào)用對(duì)應(yīng)的 javabean ，最簡(jiǎn)單的做法無(wú)非就是在 Servlet 中直接根據(jù)某種邏輯 ( 諸如反射或接口 ) 調(diào)用相應(yīng)的 bean 進(jìn)行執(zhí)行，之后將 HttpServletRequest 、 HttpServletResponse 作為參數(shù)傳入 javabean 進(jìn)行處理， javabean 從 HttpServletRequest 中獲取請(qǐng)求數(shù)據(jù)，將返回的結(jié)果數(shù)據(jù)放入 HttpServletResponse ，整個(gè)過(guò)程結(jié)束后繼續(xù)由 Controller 接手進(jìn)行處理，這個(gè)時(shí)候作為 Controller 的 servlet 將根據(jù)處理的結(jié)果返回相應(yīng)的頁(yè)面，在這個(gè)模型使用時(shí)人們慢慢的發(fā)現(xiàn)了一個(gè)問(wèn)題，那就是隨著 jsp 、 javabean 的變化造成了 controller 的不斷修改，需要修改其中調(diào)用相應(yīng) javabean 以及轉(zhuǎn)發(fā)相應(yīng)頁(yè)面的部分，為了解決這個(gè)問(wèn)題，首先想到的是應(yīng)該分離根據(jù)請(qǐng)求調(diào)用相應(yīng) javabean 的步驟，這個(gè)時(shí)候采用了設(shè)計(jì)模式中的 front controller+application controller 的方法， front controller 負(fù)責(zé)接受頁(yè)面請(qǐng)求并進(jìn)行封裝，同時(shí)將此數(shù)據(jù)對(duì)象傳遞至 application controller ，由 application controller 來(lái)負(fù)責(zé)調(diào)用相應(yīng)的 bean ，這樣的設(shè)計(jì)其實(shí)都是遵循著一個(gè)設(shè)計(jì)原則，就是職責(zé)單一，通常實(shí)現(xiàn) application controller 的模式是 Command 模式，在這種情況下 MVC Framework 的結(jié)構(gòu)體系就演變成了 view+controller(front+application)+model 。

　　在完成了上述演變后慢慢又發(fā)現(xiàn)了一個(gè)問(wèn)題，就是 model 依賴(lài)于了 httpservletrequest ，這樣造成的一個(gè)問(wèn)題就是沒(méi)法測(cè)試，仍然要不斷重啟服務(wù)器來(lái)測(cè)試，當(dāng)然與此同時(shí)的發(fā)展是 model 層的細(xì)化，細(xì)化成用于響應(yīng)頁(yè)面請(qǐng)求的 action Layer+Domain Model Layer+Persistent Layer ，在這里不去討論后面層次的問(wèn)題，因?yàn)樽鳛?MVC Framework 它并不管你 Model 層是怎么個(gè)處理流程的。

　　慢慢也發(fā)現(xiàn)了另外一個(gè)問(wèn)題，那就是變化經(jīng)常要影響到 controller 的修改，于是便引入了采用配置文件的解決方法，編寫(xiě) action 的配置文件，在配置文件中控制根據(jù) action 的返回結(jié)果轉(zhuǎn)入相應(yīng)的 View ，這樣的話在將來(lái)需要改變的時(shí)候只需要去改變這個(gè)配置文件就可以了，保證了 Controller 的穩(wěn)定，這是典型的設(shè)計(jì)中的重點(diǎn)考慮因素，分離變化和不變化的，讓變化造成的影響最小。

　　但在引入了上面的配置文件后，慢慢又發(fā)現(xiàn)了問(wèn)題，那就是手寫(xiě)配置文件總是容易出各種各樣的問(wèn)題，這個(gè)時(shí)候采用圖形化的界面來(lái)生成配置文件的想法又有了，這也就造就了 page flow 的誕生，當(dāng)然，這只是 page flow 的一小部分功能。

　　當(dāng)然，隨著MVC的發(fā)展，也帶動(dòng)了其他相關(guān)技術(shù)的發(fā)展，如異步請(qǐng)求/響應(yīng)模式(ajax、amowa，^_^)等。

　　在 MVC 思想接受后開(kāi)源界的 MVC Framework 也是如雨后春筍般的冒出，比較知名的有 struts 、 webwork 、 spring mvc 等，這些 MVC Framework 基本都已經(jīng)做到了上面提及的 MVC 思想演變的一些需求，當(dāng)然，即使現(xiàn)在的 MVC Framework 是做到了，但在使用這些 MVC Framework 的時(shí)候我們通常又開(kāi)始違背 MVC 思想的基本要素，就是保持 View 僅僅是 View 的原則，所以我比較推薦在 View 使用 Velocity 這之類(lèi)的東西作為 View ，盡量保持 View 的純潔性，任何技術(shù)的發(fā)展都是循序漸進(jìn)的，不站在那個(gè)高度的時(shí)候是不知道前面還有什么樣的高山的，那么現(xiàn)在我們?nèi)鄙俚挠质鞘裁茨?現(xiàn)在的 MVC Framework 中還存在著什么不足呢?這是值得我們思考的。