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