序號 專案名稱 描述
1 BLL 業務邏輯層
2 CacheDependencyFactory 快取依賴類的工廠類
3 WEB 表示層
4 DALFactory 資料層的抽象工廠
5 DBUtility 資料訪問類元件
6 IBLLStrategy 同步/非同步策略介面
7 ICacheDependency 快取依賴類介面
8 IDAL 資料訪問層介面定義
9 IMessaging 異時處理訊息佇列介面定義
10 IProfileDAL Profile的資料訪問層介面定義
11 Membership Membership認證和授權管理
12 MessagingFactory 異時處理訊息佇列的抽象工廠
13 Model 業務實體
14 MSMQMessaging 異時處理訊息佇列的實現
15 OracleDAL Oracle資料訪問層
16 OracleProfileDAL Oracle的Profile Providers 做使用者狀態管理，包括購物車等
17 OrderProcessor 後臺處理程式，處理訂單佇列
18 Profile Profile的資料訪問層
19 ProfileDALFactory ProfileDAL的工廠類(反射建立ProfileDAL)
20 SQLProfileDAL SQL Server 的Profile Providers 做使用者狀態管理，包括購物車等
21 SQLServerDAL SQLServer資料訪問層
22 TableCacheDependency 快取依賴實現類
專案分解：
由於整體已經有22個專案，所以，對於初學者一看就暈了，所以，我做了分解，可以大體上分幾塊去理解。
序號 專案名稱 描述
1 WEB 表示層
2 Model 業務實體
3 BLL 業務邏輯層
4 DALFactory 資料層的抽象工廠
5 IDAL 資料訪問層介面定義
6 SQLServerDAL SQLServer資料訪問層
7 OracleDAL Oracle資料訪問層
8 DBUtility 資料庫訪問元件基礎類
9 CacheDependencyFactory 快取依賴類的工廠類
10 ICacheDependency 快取依賴類介面
11 TableCacheDependency 快取依賴實現類
12 IBLLStrategy 同步/非同步處理策略介面(實現在bll根據配置反射選擇)
13 MessagingFactory 異時處理訊息佇列的抽象工廠
14 IMessaging 異時處理訊息佇列介面定義
15 MSMQMessaging 異時處理訊息佇列的實現
16 Profile Profile的資料訪問層
17 ProfileDALFactory ProfileDAL的工廠類(反射建立ProfileDAL)
18 IProfileDAL Profile的資料訪問層介面定義
19 OracleProfileDAL Oracle的Profile Providers 做使用者狀態管理
20 SQLProfileDAL SQL Server 的Profile Providers 做使用者狀態管理
21 Membership Membership認證和授權管理
22 OrderProcessor 後臺處理程式，處理訂單佇列
|
序號
|
專案名稱
|
程式集名稱Assembly Name |
預設名稱空間Default Namespace |
描述
|
|
1
|
WEB
|
|
|
表示層
|
|
2
|
Model
|
PetShop.Model |
PetShop.Model |
業務實體
|
|
3
|
BLL
|
PetShop.BLL |
PetShop.BLL |
業務邏輯層
|
|
4
|
DALFactory
|
PetShop.DAL |
PetShop.DALFactory |
資料層的抽象工廠
|
|
5
|
IDAL
|
PetShop.IDAL |
PetShop.IDAL |
資料訪問層介面定義
|
|
6
|
SQLServerDAL
|
PetShop.SQLServerDAL |
PetShop.SQLServerDAL |
SQLServer資料訪問層
|
|
7
|
OracleDAL
|
PetShop.OracleDAL |
PetShop.OracleDAL |
Oracle資料訪問層
|
|
8
|
DBUtility
|
PetShop.DBUtility |
PetShop.DBUtility |
資料庫訪問元件基礎類
|
|
9
|
CacheDependencyFactory
|
PetShop.CacheDependencyFactory |
PetShop.CacheDependencyFactory |
快取依賴類的工廠類
|
|
10
|
ICacheDependency
|
PetShop.ICacheDependency |
PetShop.ICacheDependency |
快取依賴類介面
|
|
11
|
TableCacheDependency
|
PetShop.TableCacheDependency |
PetShop.TableCacheDependency |
快取依賴實現類
|
|
12
|
IBLLStrategy
|
PetShop.IBLLStrategy |
PetShop.IBLLStrategy |
同步/非同步處理策略介面(實現在bll根據配置反射選擇)
|
|
13
|
MessagingFactory
|
PetShop.MessagingFactory |
PetShop.MessagingFactory |
異時處理訊息佇列的抽象工廠
|
|
14
|
IMessaging
|
PetShop.IMessaging |
PetShop.IMessaging |
異時處理訊息佇列介面定義
|
|
15
|
MSMQMessaging
|
PetShop.MsmqMessaging |
PetShop.MsmqMessaging |
異時處理訊息佇列的實現
|
|
16
|
Profile
|
PetShop.Profile |
PetShop.Profile |
Profile的資料訪問層
|
|
17
|
ProfileDALFactory
|
PetShop.ProfileDALFactory |
PetShop.ProfileDALFactory |
ProfileDAL的工廠類(反射建立ProfileDAL)
|
|
18
|
IProfileDAL
|
PetShop.IProfileDAL |
PetShop.IProfileDAL |
Profile的資料訪問層介面定義
|
|
19
|
OracleProfileDAL
|
PetShop.OracleProfileDAL |
PetShop.OracleProfileDAL |
Oracle的Profile Providers
做使用者狀態管理
|
|
20
|
SQLProfileDAL
|
PetShop.SQLProfileDAL |
PetShop.SQLProfileDAL |
SQL Server 的Profile Providers
做使用者狀態管理
|
|
21
|
Membership
|
PetShop.Membership |
PetShop.Membership |
Membership認證和授權管理
|
|
22
|
OrderProcessor
|
PetShop.OrderProcessor |
PetShop.OrderProcessor |
後臺處理程式，處理訂單佇列
|
一、PetShop的系統架構設計
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或成為領域層）、表示層，如圖所示：
圖一：三層的分層式結構
資料訪問層：有時候也稱為是持久層，其功能主要是負責資料庫的訪問。簡單的說法就是實現對資料表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那麼就會包括物件和資料表之間的mapping，以及物件實體的持久化。在PetShop的資料訪問層中，並沒有使用ORM，從而導致了程式碼量的增加，可以看作是整個設計實現中的一大敗筆。
業務邏輯層：是整個系統的核心，它與這個系統的業務（領域）有關。以PetShop為例，業務邏輯層的相關設計，均和網上寵物店特有的邏輯相關，例如查詢寵物，下訂單，新增寵物到購物車等等。如果涉及到資料庫的訪問，則呼叫資料訪問層。
表示層：是系統的UI部分，負責使用者與整個系統的互動。在這一層中，理想的狀態是不應包括系統的業務邏輯。表示層中的邏輯程式碼，僅與介面元素有關。在PetShop中，是利用ASP.Net來設計的，因此包含了許多Web控制元件和相關邏輯。
分層式結構究竟其優勢何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一書中給出了答案：
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的複用。
概括來說，分層式設計可以達至如下目的：分散關注、鬆散耦合、邏輯複用、標準定義。
一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。例如UI人員只需考慮使用者介面的體驗與操作，領域的設計人員可以僅關注業務邏輯的設計，而資料庫設計人員也不必為繁瑣的使用者互動而頭疼了。每個開發人員的任務得到了確認，開發進度就可以迅速的提高。
鬆散耦合的好處是顯而易見的。如果一個系統沒有分層，那麼各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發生改變，則牽一髮而動全身，對專案的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴充套件，在複用性上也是優勢明顯。每個功能模組一旦定義好統一的介面，就可以被各個模組所呼叫，而不用為相同的功能進行重複地開發。
進行好的分層式結構設計，標準也是必不可少的。只有在一定程度的標準化基礎上，這個系統才是可擴充套件的，可替換的。而層與層之間的通訊也必然保證了介面的標準化。
“金無足赤，人無完人”，分層式結構也不可避免具有一些缺陷：
1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的程式碼。
前面提到，PetShop的表示層是用ASP.Net設計的，也就是說，它應是一個BS系統。在.Net中，標準的BS分層式結構如下圖所示：
圖二：.Net中標準的BS分層式結構
隨著PetShop版本的更新，其分層式結構也在不斷的完善，例如PetShop2.0，就沒有采用標準的三層式結構，如圖三：
圖三：PetShop 2.0的體系架構
從圖中我們可以看到，並沒有明顯的資料訪問層設計。這樣的設計雖然提高了資料訪問的效能，但也同時導致了業務邏輯層與資料訪問的職責混亂。一旦要求支援的資料庫發生變化，或者需要修改資料訪問的邏輯，由於沒有清晰的分層，會導致專案作大的修改。而隨著硬體系統效能的提高，以及充分利用快取、非同步處理等機制，分層式結構所帶來的效能影響幾乎可以忽略不計。
PetShop3.0糾正了此前層次不明的問題，將資料訪問邏輯作為單獨的一層獨立出來：
圖四：PetShop 3.0的體系架構
PetShop4.0基本上延續了3.0的結構，但在效能上作了一定的改進，引入了快取和非同步處理機制，同時又充分利用了ASP.Net 2.0的新功能MemberShip，因此PetShop4.0的系統架構圖如下所示：
圖五：PetShop 4.0的體系架構
比較3.0和4.0的系統架構圖，其核心的內容並沒有發生變化。在資料訪問層（DAL）中，仍然採用DAL Interface抽象出資料訪問邏輯，並以DAL Factory作為資料訪問層物件的工廠模組。對於DAL Interface而言，分別有支援MS-SQL的SQL Server DAL和支援Oracle的Oracle DAL具體實現。而Model模組則包含了資料實體物件。其詳細的模組結構圖如下所示：
圖六：資料訪問層的模組結構圖
可以看到，在資料訪問層中，完全採用了“面向介面程式設計”思想。抽象出來的IDAL模組，脫離了與具體資料庫的依賴，從而使得整個資料訪問層利於資料庫遷移。DALFactory模組專門管理DAL物件的建立，便於業務邏輯層訪問。SQLServerDAL和OracleDAL模組均實現IDAL模組的介面，其中包含的邏輯就是對資料庫的Select，Insert，Update和Delete操作。因為資料庫型別的不同，對資料庫的操作也有所不同，程式碼也會因此有所區別。
此外，抽象出來的IDAL模組，除了解除了向下的依賴之外，對於其上的業務邏輯層，同樣僅存在弱依賴關係，如下圖所示：
圖七：業務邏輯層的模組結構圖
圖七中BLL是業務邏輯層的核心模組，它包含了整個系統的核心業務。在業務邏輯層中，不能直接訪問資料庫，而必須通過資料訪問層。注意圖中對資料訪問業務的呼叫，是通過介面模組IDAL來完成的。既然與具體的資料訪問邏輯無關，則層與層之間的關係就是鬆散耦合的。如果此時需要修改資料訪問層的具體實現，只要不涉及到IDAL的介面定義，那麼業務邏輯層就不會受到任何影響。畢竟，具體實現的SQLServerDAL和OracalDAL根本就與業務邏輯層沒有半點關係。
因為在PetShop 4.0中引入了非同步處理機制。插入訂單的策略可以分為同步和非同步，兩者的插入策略明顯不同，但對於呼叫者而言，插入訂單的介面是完全一樣的，所以PetShop 4.0中設計了IBLLStrategy模組。雖然在IBLLStrategy模組中，僅僅是簡單的IOrderStategy，但同時也給出了一個範例和資訊，那就是在業務邏輯的處理中，如果存在業務操作的多樣化，或者是今後可能的變化，均應利用抽象的原理。或者使用介面，或者使用抽象類，從而脫離對具體業務的依賴。不過在PetShop中，由於業務邏輯相對簡單，這種思想體現得不夠明顯。也正因為此，PetShop將核心的業務邏輯都放到了一個模組BLL中，並沒有將具體的實現和抽象嚴格的按照模組分開。所以表示層和業務邏輯層之間的呼叫關係，其耦合度相對較高：
圖八：表示層的模組結構圖
在圖五中，各個層次中還引入了輔助的模組，如資料訪問層的Messaging模組，是為非同步插入訂單的功能提供，採用了MSMQ（Microsoft Messaging Queue）技術。而表示層的CacheDependency則提供快取功能。這些特殊的模組，我會在此後的文章中詳細介紹。