"解耦"的思想一直是我們倡導的,但在實際專案中怎樣去做?這是需要我們去好好思考的。下面以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、三層是在解耦的基礎上一步步進化而來，通過解耦我們可以進行進一步的抽象，以應對現實需求的變動。