以前做系統是按照三層的思想來做的，即u ，b ，d 。坐著坐著，開始不斷加入設計模式，加入sqlhelper ，漸漸的知道了系統不只可以分三層，原來是可以分很多層的，隨著學習的不斷深入明白了「為什麼會出現分層」。知道了是一回事，關鍵還是在「怎麼用」，所以我們還在為「分層」而進行不懈的努力著……
現在學習到了drp，又認識了乙個分層：mvc（model-view-control）。
正式語言這麼描述：用一種業務邏輯、資料、介面顯示分離的方法組織**，將業務邏輯聚集到乙個部件裡面，在改進和個性化定製介面及使用者互動的同時，不需要重新編寫業務邏輯。對於有系統經驗的朋友們，對這些描述是深有感悟。下面我們來簡單看一下這個模型的始末。
一、mvc 的前身
乙個很簡單的呼叫，從前端到jsp到業務邏輯。
圖中可以看出它的優點：結構簡單，容易操作。
再看第二眼：鎖定jsp ，1、取得頁面引數，
2、呼叫業務邏輯，
3、到返回資料
4、渲染頁面
5、將渲染結果response 給前端頁面
如果要給jsp職責分類的話，1~3，是一致的，那麼4 （渲染頁面）就顯得格格不入，因為，我們有前端，這個jsp既有「業務邏輯處理」，又有「頁面處理」，這在三層中，該屬於u,b 混搭了。
所以他的缺點就是： 職責不單一，責任過重，不便於維護。但是這個適合小型專案的開發。
任何分層思想都是一樣的，就是為了「職責單一，便於管理」，這裡既然分層不徹底，那麼就重新分唄，有了mvc。
二、mvc
這個圖就解決了「混搭」的問題，相對於剛才那個，這個模型適合大型專案開發。
通過引入servlet 來分擔jsp中呼叫「業務邏輯」的功能，讓jsp 只做「渲染頁面」來實現頁面和業務邏輯的排排站。
這裡做到了前端和業務邏輯的分離，但是之前我們說了，乙個系統不止有「x」層，我們所熟知的「層」，是通用的寫好的一種規範，在實際中，我們可以根據業務需要在「已知層」上進行抽象，包裝屬於「系統」的層。接下來要說的只是在mvc的基礎上加乙個「資料訪問」的層。當然，這個不屬於某乙個系**有，基本所有的系統都會涉及到資料庫的訪問，和資料庫連線的驅動分，方法等基本都是一致的，所以可以封裝成一層，作為「持久層」。
一般持久層的使用都會和dao配合，在dao中使用了「工廠模式」，封裝建立過程。
在持久層的設計中有幾個重要的原則：細粒度————細粒度的目的是為了達到高復用性。
：要單純————不涉及或者很少有過多的業務邏輯。
一步一步進化的模型，就是一種思想的演變。有一種思想很重要，行動上要懶惰，思想上要積極。為了自己可以在行動上懶惰，而發動思維運動，這就是「**復用」。
DRP學習進化模型
曾經做的就是按照思維做的 制，這是u b d 坐在坐，開始增加設計模式，增加sqlhelper 逐漸了解系統可分為只三層，層的，隨著學習的不斷深入明確了 為什麼會出現分層 知道了是一回事，關鍵還是在 怎麼用 所以我們還在為 分層 而進行不懈的努力著 如今學習到了drp。又認識了乙個分層 mvc mo...
單例模式在DRP中的應用
此次 drp專案主要對企業的物流和資金流進行全面的管理和控制，從而縮短企業的 鏈，為企業節省成本，為管理層提供全面的資訊流。本系統主要包括如下模組，商及其庫存管理 分銷費管理 結賬管理 付款結算管理 統計報表管理 基礎資料管理和系統管理。整個系統採用分層的思想，通過呼叫訪問資料庫類 dbutil 訪...
單例模式在DRP中的應用
此次 drp專案主要對企業的物流和資金流進行全面的管理和控制，從而縮短企業的 鏈，為企業節省成本，為管理層提供全面的資訊流。本系統主要包括如下模組，商及其庫存管理 分銷費管理 結賬管理 付款結算管理 統計報表管理 基礎資料管理和系統管理。整個系統採用分層的思想，通過呼叫訪問資料庫類 dbutil 訪...