"解耦"的思想一直是我們倡導的,但在實際項目中怎樣去做?這是需要我們去好好思考的。下面以Model1、Model2、三層為切入點，對比下去了解解耦的思想。
Model1
使用JSP頁面和JavaBean相結合的方式，由JSP頁面來接收客戶端請求，用JavaBean或其他服務完成業務邏輯、數據庫操作和返回頁面。我們這里的JavaBean主要是完成特定功能的Java類。
優點：架構簡單，比較適合小型項目開發
缺點：JSP職責不單一，職責過重，不便於維護
Model2（MVC）
Model1雖然在一定程度上解耦了，但JSP依舊即要負責頁面控制，又要負責邏輯處理，職責不單一。此時Model2應運而生，使得各個部分各司其職。 Model2基於MVC模式:
Controller：應用程序中用戶交互部分（Servlet）
Model：應用程序數據邏輯部分（JavaBeans）
View：數據顯示部分（JSP）
優點：職責清晰，較適合於大型項目架構
缺點：分層較多，不適合小型項目開發
區別：
Model2在Model1的基礎上分離了控制，將JSP中的邏輯操作部分分離出來，這樣做不僅減輕了JSP的職責，而且更有利於分工開發，耦合性降低。
對於復雜的Web應用開發，更適合使用Model2；而對於小型應用，使用Model1比較簡單。
三層
Model2巧妙的將JSP中的業務邏輯部分分給了Servlet，使得頁面控制與邏輯處理徹底分離，達到了部分解耦的目的。但我們現實項目開發中，往往在Model2的基礎上又進行了分層。將業務邏輯細分為業務邏輯和持久化邏輯兩層。
往往使用一個Dao接口隱藏持久化操作的細節，業務對象不需要了解底層的數據庫持久化知識。使得業務邏輯與持久化邏輯分離，業務邏輯通常關系的是應用程序的核心流程和業務規則，持久化邏輯關注的是如何訪問和操作持久化數據。
表示層，JSP/Servlet
業務邏輯層：業務規則
持久化層：主要包裝持久化的邏輯
分層主要目的是為了好管理，能更好的適應需求的變換，能夠更好的進行人員分工。
表示層、業務邏輯層、持久層是自上而下的依賴，依賴於抽象
程序對JDBC的依賴就是依賴了他的抽象層，如：連接數據庫用的Connection，我們只能看到其接口，而不能看到其實現，具體的實現封裝在JDBC包中。JDBC已經包裝好，我們只需要引入不同實現，以適應數據庫的變化。
總結：
Model1、Model2、三層是在解耦的基礎上一步步進化而來，通過解耦我們可以進行進一步的抽象，以應對現實需求的變動。