DRP學習進化模型

曾經做的就是按照思維做的**制，這是u 。b ，d 。坐在坐，開始增加設計模式，增加sqlhelper ，逐漸了解系統可分為只三層，層的，隨著學習的不斷深入明確了「為什麼會出現分層」。知道了是一回事，關鍵還是在「怎麼用」，所以我們還在為「分層」而進行不懈的努力著……

如今學習到了drp。又認識了乙個分層：mvc（model-view-control）。

正式語言這麼描寫敘述：用一種業務邏輯、資料、介面顯示分離的方法組織**，將業務邏輯聚集到乙個部件裡面，在改進和個性化定製介面及使用者互動的同一時候。不須要又一次編寫業務邏輯。對於有系統經驗的朋友們，對這些描寫敘述是深有感悟。

以下我們來簡單看一下這個模型的始末。

一、mvc 的前身

乙個非常easy的呼叫，從前端到jsp到業務邏輯。

圖中能夠看出它的長處：結構簡單，easy操作。

再看第二眼：鎖定jsp 。1、取得頁面引數，

2、呼叫業務邏輯。

3、到返回資料

4、渲染頁面

5、將渲染結果response 給前端頁面

假設要給jsp職責分類的話，1~3，是一致的。那麼4 （渲染頁面）就顯得格格不入，由於，我們有前端，這個jsp既有「業務邏輯處理」，又有「頁面處理」，這在三層中。該屬於u,b 混搭了。

所以他的缺點就是：職責不單一，責任過重，不便於維護。可是這個適合小型專案的開發。

不論什麼分層思想都是一樣的，就是為了「職責單一。便於管理」，這裡既然分層不徹底。那麼就又一次分唄。有了mvc。

二、mvc

這個圖就攻克了「混搭」的問題，相對於剛才那個，這個模型適合大型專案開發。

通過引入servlet 來分擔jsp中呼叫「業務邏輯」的功能。讓jsp 僅僅做「渲染頁面」來實現頁面和業務邏輯的排排站。

這裡做到了前端和業務邏輯的分離，可是之前我們說了，乙個系統不止有「x」層，我們所熟知的「層」。是通用的寫好的一種規範，在實際中，我們能夠依據業務須要在「已知層」上進行抽象。包裝屬於「系統」的層。

接下來要說的僅僅是在mvc的基礎上加乙個「資料訪問」的層。當然。這個不屬於某乙個系**有。基本全部的系統都會涉及到資料庫的訪問，和資料庫連線的驅動分，方法等基本都是一致的。所以能夠封裝成一層，作為「持久層」。

一般持久層的使用都會和dao配合，在dao中使用了「工廠模式」，封裝建立過程。

在持久層的設計中有幾個重要的原則：細粒度————細粒度的目的是為了達到高復用性。

：要單純————不涉及或者非常少有過多的業務邏輯。

一步一步進化的模型，就是一種思想的演變。有一種思想非常重要。行動上要懶惰，思想上要積極。為了自己能夠在行動上懶惰，而發動思維運動，這就是「**復用」。