使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節，將不同的功能代碼分散開來，更利于系統的設計和開發，同時為可能的變更提供了更小的單元。

以下就是一個典型的多層體系結構圖。



首先我們以“訂單(Order)”為例，進行一個簡單的業務分解。

1. 訂單自然包括訂單的內容(OrderInfo)，其中有諸如訂單編號、商品名稱、數量，以及金額等信息。
2. 有了訂單信息，我們還需要一個存儲訂單的場所，那么自然需要有個操作讀寫的對象(OrderAccess)。
3. 為了外界能進行相關的訂單操作，我們還需要有個業務邏輯對象(Order)，它提供創建新訂單，向訂單插入/刪除商品，保存訂單等操作。

通過上面的分析，我們基本上可以將一個業務邏輯完整地分割為：

業務實體 ---> OrderInfo
數據訪問 ---> OrderAccess
業務邏輯 ---> Order

基于系統架構考慮，我們將這些對象分別放置在不同的邏輯單元中，這些邏輯單元就組成了“多層”。

業務實體層(Model) ---> 業務實體 ---> OrderInfo
數據訪問層(DAL) ---> 數據訪問 ---> OrderAccess
業務邏輯層(BLL) ---> 業務邏輯 ---> Order

同樣以上面訂單為例，我們進一步講述各層對象的實現細節。

1. 客戶基本上只依賴于 Order 和 OrderInfo，通過他們就可以操作業務的全部，它并不關心業務存儲等細節。

2. 大多數時候我們會將 OrderAccess 設計成 Internal Protected 方式，OrderAccess 可以是一個抽象類或者接口。我更習慣于將其實現為抽象類，因為某些方法是調用其他方法來實現的，抽象類的設計可以減少實現類的代碼數量。另外將該抽象類設計成工廠方法模式，通過 IoC 或者 "配置反射" 來獲得具體的實現類，可以減少層之間的耦合，也便于數據系統的替換。

3. Order 多數時候可以實現為 Singleton 或者靜態類，它只是提供了一系列的方法來操作某些邏輯，通過接受 OrderInfo 參數來獲取信息。其本身無需保存任何狀態。如果需要實現購物車，只需將 OrderInfo 存儲到 Session 之中即可。

通過上面的例子，我們還可以發現多層的另外一個好處就是更利于團隊協作開發。架構設計人員無需考慮具體的數據庫實現代碼，而將設計重點放在業務層面；數據庫開發人員自然也可將重心放在數據庫訪問優化上。團隊成員之間不再是一人負責一個業務模塊，不再有了 n 個數據訪問類，不再有 n 種不同的對象模式等等。從傳統的 "瓦罐作坊" 演變為 "工業流水線"，更利于根據技術能力和業務熟悉度的差別來劃分不同的角色。