主要是使用設計模式的思想，對于項目的各個模塊實現"高内聚，低耦合"的思想。這裏就不做詳細的介紹了，如果大家有興趣，可以閱讀軟件工程和設計模式相關文章。

對于三層架構來說，就是使用類，把我們在做項目的過程中，可能需要反複操作數據庫，反複的使用某個方法等等，可能就是操作的參數不同。如果我們如果在每次使用的時候，都去編寫相應的代碼，無疑會增加程序員的負擔。所以，爲了增加方法的重用，就把這些能夠重用的方法抽象成類，以供程序員在其它地方可以調用。

三層結構通常是指數據訪問層、業務邏輯層和表示層。三層結構之間的關系如圖18-2所示。

表示層位于最上層，用于顯示和接收用戶提交的數據，爲用戶提供交互式的界面。表示層一般爲Windows窗體應用程序或Web應用程序。

業務邏輯層是表示層和數據訪問層之間溝通的橋梁，主要負責數據的傳遞和處理。

　業務邏輯層在體系架構中的位置很關鍵，它處于數據訪問層與表示層中間，起到了數據交換中承上啓下的作用。由于層是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那麽這種向下的依賴也應該是一種弱依賴關系。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正因爲如此，業務邏輯層的設計對于一個支持可擴展的架構尤爲關鍵，因爲它扮演了兩個不同的角色。對于數據訪問層而言，它是調用者；對于表示層而言，它卻是被調用者。依賴與被依賴的關系都糾結在業務邏輯層上，如何實現依賴關系的解耦，則是除了實現業務邏輯之外留給設計師的任務。