【正文】 配置反射選擇 ) 13 MessagingFactory 異時處理消息隊列的 抽象工廠 14 IMessaging 異時處理消息隊列接口定義 15 MSMQMessaging 異時處理消息隊列的實現 16 Profile Profile的數據訪問層 17 ProfileDALFactory ProfileDAL 的工廠類 (反射創(chuàng)建 ProfileDAL) 18 IProfileDAL Profile的數據訪問層接口定義 19 OracleProfileDAL Oracle的 Profile Providers 做用戶狀態(tài)管理 20 SQLProfileDAL SQL Server 的 Profile Providers 做用戶狀態(tài)管理 21 Membership Membership 認證和授權管理 22 OrderProcessor 后臺處理進程，處理訂單隊列 3． Petshop 4 中的設計模式 ： 工廠模式 : 首當其沖的就是工廠模式，很容易就可以看出來，也是應用最多的。 // Run a search against the data store return (category)。新的 Petshop4 實現了與 Petshop 3相同甚至更多的特性，由于采用了 Master Pages， Membership，以及 Profile， SqlCacheDependency，但是代碼量卻減少了四分之一。用戶做比較的這個項目就是 Petshop。1．項目概述與架構分析 微軟剛推出了基于 下的 Pet Shop 4, 該版本有了一個全新的用戶界面。正因為 Petshop 肩負著上面所說的重任，各方面必須是最優(yōu)的，架構設計應該是經過慎重考慮的。同時，在事務、數據緩存、安全方面使用了 .NET 附帶的特性，構建了一個靈活的最佳實踐的應用程序。 } 3．采用 Membership 來做認證和授權 4．創(chuàng)建了針對 Oracle 10g 的 Custom Membership Provider 5．利用 的 Custom Oracle 和 SQL Server Profile Providers 做用戶狀態(tài)管理，包括購物車等 6．采用了 Master Pages，取代了原來的用戶控件，來實現統(tǒng)一的界面效果 7．使用了 Wizard 控件實現 checkout 8．使用了 SqlCacheDependency 來實現數據庫層次的緩存更新 (cache invalidation)功能 9．使用了消息隊列來實現異時訂單處理。 DALFactory：數據訪問層的抽象工廠（決定創(chuàng)建哪種數據庫類型的數據訪問層。在 PetShop 中，由于引入了 的一些新特色，所以數據層的內容也更加的廣泛和復雜，包括：數據庫訪問、 Messaging、 MemberShip、 Profile四部分。這些實體類都被放到 Model 程序集中，例如數據表 Order 對應的實體類 OrderInfo，其類圖如下： 這些對象并不具有持久化的功能，簡單地說，它們是作為數據的載體，便于業(yè)務邏輯針對相應數據表進行讀 /寫操作。這里所指的業(yè)務邏輯，并非業(yè)務邏輯層意義上的領域（ domain）業(yè)務邏輯（從這個意義上，我更傾向于將業(yè)務邏輯層稱為 “領域邏輯層 ”），一般意義上說，這些業(yè)務邏輯即為基本的數據庫操作，包括 Select， Insert， Update 和 Delete。其次，它體現了 “抽象 ”的精神，或者說是 “面向接口編程 ”的最佳體現。 以 Order 為例，在 SQLServerDAL、 OracleDAL 兩個模塊中，有不同的實現，但它們同時又都實現了 IOrder 接口，如圖： 從數據庫的實現來看， PetShop 體現出了沒有 ORM 框架的臃腫與丑陋。 在沒有 ORM 的情況下，使用 Helper 類是一個比較好的策略，利用它來完成數據庫基本操作的封裝，可以減少很多和數據庫操作有關的代碼，這體現了對象復用的原則。在早期的 CS 結構中，由于未采用三層式架構設計，數據訪問層和業(yè)務邏輯層是緊密糅合在一起的， 因此， SQL語句遍布與系統(tǒng)的每一個角落。這種方法使得程序更加整潔，此外，由于存儲過程可以以數據庫腳本的形式存在，也便于移植和修改。二是對系統(tǒng)的更新帶來障礙。如要使用相關的 SQL語句，就利用關鍵字搜索獲得對應語句。不過， 利用良好的設計，我們可以為各種業(yè)務提供不同的表來存放 SQL語句。 當然，如果應用 ORM，那么一切就變得不同了。 try { trans = ()。 } } 沒有 SQL語句，也沒有那些煩人的 Parameters，甚至不需要專門去考慮事務。至少，那些在數據訪問層中占據了絕大部分的 CRUD 操作，通過利用 ORM 框架，我們就僅需要付出極少數時間和精力來解決它們了。留待我們的還有兩個問題需要解決： 數據對象創(chuàng)建的管理 利于數據庫的移植 在 PetShop 中，要創(chuàng)建的數據對象包括 Order， Product， Category， Inventory， Item。標準的抽象工廠模式類圖如下： 例如，創(chuàng)建 SQL Server 的 Order 對象如下： PetShopFactory factory = new SQLServerFactory()。一旦整個系統(tǒng)要求支持 Oracle，那么還需要修改這行代碼為： PetShopFactory factory = new OracleFactory()。而在 .Net平臺下，最常見的則是 。那么，抽象工廠模式中的相關工廠就可以簡化為一個工廠類了，所以我將這種模式稱之為 “具有簡單工廠特 質的抽象工廠模式 ”，其類圖如下： DataAccess類完全取代了前面創(chuàng)建的工廠類體系，它是一個 sealed 類，其中創(chuàng)建各種數據對象的方法，均為靜態(tài)方法。 return ()(orderPath).CreateInstance(className)。 private static readonly string orderPath = [”O(jiān)rdersDAL”]。 } public static object LocateDALOrderObject(string className) { string fullPath = orderPath + “.” + className。 } //…… } 那么和所謂 “依賴注入 ”相關的代碼都可以利用 ServiceLocator 來完成。 工廠設計模式是這樣實現的： 創(chuàng)建一個 C 接口，其中對于數據庫訪問類必須公開的每個方法都要聲明一個方法。 為了使應用程序更安全，為版本控制提供更好的支持，我們可以在應 用程序配置文件（也就是這里的 . ）中添加要加載的程序集文件的 “證據 ”，這意味著 .NET 框架將只加載我們在編譯期間簽過名而且有正確版本號的程序集。 創(chuàng)建 DB2 兼容版本的步驟如下： DB2 的數據庫訪問類 ，它應該實現 IDAL 接口。 無需更改或重新編譯業(yè)務邏輯組件。這樣系統(tǒng)上層只管調用，而下層來實現細節(jié)， 上級只管發(fā)號施令，下級去干活。 string className = path + .Account。因為我在安裝 時選擇的是 Sqlserver 所以在此是：value=，如果用的是 Oracle 那就是value= 了吧！而且這個文件也應該是可以更改的。 AccountInf