使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節，將不同的功能**分散開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元。
以下就是乙個典型的多層體系結構圖。
首先我們以「訂單(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 種不同的物件模式等等。從傳統的 "瓦罐作坊" 演變為 "工業流水線"，更利於根據技術能力和業務熟悉度的差別來劃分不同的角色。
推薦：多層 + ioc 絕對是個不錯的選擇。
多層架構簡述
分類 多層架構 2007 06 20 14 47 2247人閱讀收藏 舉報 資料庫ioc 架構設計 儲存session作業 使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節，將不同的功能 分散開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元。以下就是乙個典型的多層體系...
c 多層架構
三層結構 表現層，業務邏輯層，資料訪問層。功能 表現層 資料的現實和接收使用者輸入的資料 為使用者提供一種互動式操作的介面 業務邏輯層 處理資料 它處於表現層與資料訪問層之間，起到了資料互動中承上啟下的作用。資料訪問層 持久層 實現了對資料的儲存和讀取操作。它還負責想業務邏輯層提供資料和修改資料的操...
多層架構 轉載
多層結構就像多個人，分別不同負責各自的工作。該知道自己知道的，不該知道自己不知道的。別八卦，別打聽不該自己知道的事。表示層 不應該知道的 不應該看到物理的資料儲存。不應該有connection strings,connections,commands或者類似。應該知道的 應該知道主要模組。業務邏輯層...