使用多層架構(gòu)進(jìn)行系統(tǒng)開發(fā)是現(xiàn)今系統(tǒng)設(shè)計(jì)的流行趨勢。通過分解業(yè)務(wù)細(xì)節(jié)，將不同的功能代碼分散開來，更利于系統(tǒng)的設(shè)計(jì)和開發(fā)，同時為可能的變更提供了更小的單元。

以下就是一個典型的多層體系結(jié)構(gòu)圖。



首先我們以“訂單(Order)”為例，進(jìn)行一個簡單的業(yè)務(wù)分解。

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

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

業(yè)務(wù)實(shí)體 ---> OrderInfo
數(shù)據(jù)訪問 ---> OrderAccess
業(yè)務(wù)邏輯 ---> Order

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

業(yè)務(wù)實(shí)體層(Model) ---> 業(yè)務(wù)實(shí)體 ---> OrderInfo
數(shù)據(jù)訪問層(DAL) ---> 數(shù)據(jù)訪問 ---> OrderAccess
業(yè)務(wù)邏輯層(BLL) ---> 業(yè)務(wù)邏輯 ---> Order

同樣以上面訂單為例，我們進(jìn)一步講述各層對象的實(shí)現(xiàn)細(xì)節(jié)。

1. 客戶基本上只依賴于 Order 和 OrderInfo，通過他們就可以操作業(yè)務(wù)的全部，它并不關(guān)心業(yè)務(wù)存儲等細(xì)節(jié)。

2. 大多數(shù)時候我們會將 OrderAccess 設(shè)計(jì)成 Internal Protected 方式，OrderAccess 可以是一個抽象類或者接口。我更習(xí)慣于將其實(shí)現(xiàn)為抽象類，因?yàn)槟承┓椒ㄊ钦{(diào)用其他方法來實(shí)現(xiàn)的，抽象類的設(shè)計(jì)可以減少實(shí)現(xiàn)類的代碼數(shù)量。另外將該抽象類設(shè)計(jì)成工廠方法模式，通過 IoC 或者 "配置反射" 來獲得具體的實(shí)現(xiàn)類，可以減少層之間的耦合，也便于數(shù)據(jù)系統(tǒng)的替換。

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

通過上面的例子，我們還可以發(fā)現(xiàn)多層的另外一個好處就是更利于團(tuán)隊(duì)協(xié)作開發(fā)。架構(gòu)設(shè)計(jì)人員無需考慮具體的數(shù)據(jù)庫實(shí)現(xiàn)代碼，而將設(shè)計(jì)重點(diǎn)放在業(yè)務(wù)層面；數(shù)據(jù)庫開發(fā)人員自然也可將重心放在數(shù)據(jù)庫訪問優(yōu)化上。團(tuán)隊(duì)成員之間不再是一人負(fù)責(zé)一個業(yè)務(wù)模塊，不再有了 n 個數(shù)據(jù)訪問類，不再有 n 種不同的對象模式等等。從傳統(tǒng)的 "瓦罐作坊" 演變?yōu)?"工業(yè)流水線"，更利于根據(jù)技術(shù)能力和業(yè)務(wù)熟悉度的差別來劃分不同的角色。