解耦合的設計目標：
    1. 應用層解耦合--應用邏輯與數據邏輯相分離。
    2. 資源層解耦合--邏輯結構與物理結構相分離。

DAO模式：即Data Accessor模式和Active Domain Object模式。
    Data Accessor模式：實現數據訪問和業務邏輯的分離。
    Active Domain Object：實現了業務數據的對象化封裝。
    Domain Object：簡單來講就是對領域內涉及的各個數據對象，反映到代碼，就是一個擁有相關屬性的getter，setter方法的java Bean。

    DAO模式通過對業務邏輯蹭提供數據抽象層接口，實現了以下目標：
        1. 數據存儲邏輯的分離：通過對數據訪問邏輯進行抽象，為上層結構提供抽象化的數據訪問接口。
        2. 數據訪問底層實現的分離：數據訪問劃分為抽象層和實現層，從而分離了數據使用和數據訪問的底層實現細節。
        3. 資源管理和調用的分離。
        4.數據抽象：DAO模式通過對底層數據的封裝，為業務層提供了一個面向對象的接口，使得業務邏輯開發人員可以面向業務中的實體進行編程。
        DAO = Data+Accessor+Domain Object

DAO模式的進一步改良
    Factory模式的引入：
        由于需要針對不同的數據庫訪問機制分別提供各個版本的Data Accessor實現，自然我們會想到通過java interface定義一個調用接口，然后針對這個調用接口實現不同數據庫的Data Accessor。通過接口作為調用界面和實現規范，可以避免對具體實現的依賴。
        
作為最常見的創建模式，Factory模式在這里起到連接接口和實現的橋梁作用，通過Factory模式，我們可以根據具體的需要加載相應的實現，并將此實現作為所對應接口的一個實例提供給業務層使用。
業務邏輯層通過接口調用底層實現，具體的DAO實現類不會出現在我們的業務代碼中。而具體實現類在配置文件中加以配置，之后DAOFactory.getDAO方法通過讀取配置文件獲得當前我們期望使用的實現類的類名，再通過java Class動態加載機制加載返回。
從而我們的代碼不依賴于某個特定的實現類，只需要在部署的時候在配置文件中指定當前采用的實現類即可。

ClassToolKit.loadClass方法實現了類文件的動態加載：
這樣，通過接口與實現的分離，并結合DAOFactory動態加載實現類，我們就實現了底層訪問實現的參數化配置功能。從而為增強產品的部署能力提供了強有力的支持。
    經過Factory模式的改造，業務層代碼進行相應的修改：
這段代碼中混雜了數據訪問層的內容，如DAOFactory.getDAO方法的調用。

Proxy模式的引入
    為了保持業務邏輯代碼的簡潔，將Factory模式帶來的Bad Smell排除在系統外，引入Proxy模式。
    Proxy模式的作用：通過提供一個中間層（Proxy），將上層調用接口與下層實現相銜接。
    經過Proxy模式改進后的業務層代碼：