【正文】 以我將這種模式稱之為“具有簡單工廠特質(zhì)的抽象工廠模式”，其類圖如下：DataAccess類完全取代了前面創(chuàng)建的工廠類體系，它是一個sealed類，其中創(chuàng)建各種數(shù)據(jù)對象的方法，均為靜態(tài)方法。之所以能用這個類達(dá)到抽象工廠的目的，是因?yàn)榕渲梦募头瓷涞倪\(yùn)用，如下的代碼片斷所示：public sealed class DataAccess{// Look up the DAL implementation we should be using private static readonly string path = [”WebDAL”]。 private static readonly string orderPath = [”O(jiān)rdersDAL”]。public static CreateOrder(){ string className = orderPath + “.Order”。 return ()(orderPath).CreateInstance(className)。 }}在PetShop中，這種依賴配置文件和反射創(chuàng)建對象的方式極其常見，包括IBLLStategy、CacheDependencyFactory等等。這些實(shí)現(xiàn)邏輯散布于整個PetShop系統(tǒng)中，在我看來，是可以在此基礎(chǔ)上進(jìn)行重構(gòu)的。也就是說，我們可以為整個系統(tǒng)提供類似于“Service Locator”的實(shí)現(xiàn)：public static class ServiceLocator{private static readonly string dalPath = [”WebDAL”]。 private static readonly string orderPath = [”O(jiān)rdersDAL”]。//……private static readonly string orderStategyPath = [”O(jiān)rderStrategyAssembly”]。public static object LocateDALObject(string className){string fullPath = dalPath + “.” + className。return (dalPath).CreateInstance(fullPath)。}public static object LocateDALOrderObject(string className){string fullPath = orderPath + “.” + className。return (orderPath).CreateInstance(fullPath)。}public static object LocateOrderStrategyObject(string className){string fullPath = orderStategyPath + “.” + className。return (orderStategyPath).CreateInstance(fullPath)。}//……}那么和所謂“依賴注入”相關(guān)的代碼都可以利用ServiceLocator來完成。例如類DataAccess就可以簡化為：public sealed class DataAccess{public static CreateOrder(){ return ()ServiceLocator. LocateDALOrderObject(”O(jiān)rder”)。 }}通過ServiceLocator，將所有與配置文件相關(guān)的namespace值統(tǒng)一管理起來，這有利于各種動態(tài)創(chuàng)建對象的管理和未來的維護(hù)。 PetShop數(shù)據(jù)訪問層之消息處理PetShop數(shù)據(jù)訪問層之消息處理Filed under: Design amp。 Pattern — bruce zhang @ 12:11 pm 《解剖PetShop》系列之三三、PetShop數(shù)據(jù)訪問層之消息處理 在進(jìn)行系統(tǒng)設(shè)計時，除了對安全、事務(wù)等問題給與足夠的重視外，性能也是一個不可避免的問題所在，尤其是一個B/S結(jié)構(gòu)的軟件系統(tǒng)，必須充分地考慮訪問量、數(shù)據(jù)流量、服務(wù)器負(fù)荷的問題。解決性能的瓶頸，除了對硬件系統(tǒng)進(jìn)行升級外，軟件設(shè)計的合理性尤為重要。 在前面我曾提到，分層式結(jié)構(gòu)設(shè)計可能會在一定程度上影響數(shù)據(jù)訪問的性能，然而與它給設(shè)計人員帶來的好處相比，幾乎可以忽略。要提供整個系統(tǒng)的性能，還可以從數(shù)據(jù)庫的優(yōu)化著手，例如連接池的使用、建立索引、優(yōu)化查詢策略等等，例如在PetShop中就利用了數(shù)據(jù)庫的Cache，對于數(shù)據(jù)量較大的訂單數(shù)據(jù)，則利用分庫的方式為其單獨(dú)建立了Order和Inventory數(shù)據(jù)庫。而在軟件設(shè)計上，比較有用的方式是利用多線程與異步處理方式。 ，使用了Microsoft Messaging Queue(MSMQ)技術(shù)來完成異步處理，利用消息隊(duì)列臨時存放要插入的數(shù)據(jù)，使得數(shù)據(jù)訪問因?yàn)椴恍枰L問數(shù)據(jù)庫從而提供了訪問性能，至于隊(duì)列中的數(shù)據(jù)，則等待系統(tǒng)空閑的時候再進(jìn)行處理，將其最終插入到數(shù)據(jù)庫中。 ，主要分為如下幾部分：消息接口IMessaging、消息工廠MessagingFactory、MSMQ實(shí)現(xiàn)MSMQMessaging以及數(shù)據(jù)后臺處理應(yīng)用程序OrderProcessor。從模塊化分上，PetShop自始自終地履行了“面向接口設(shè)計”的原則，將消息處理的接口與實(shí)現(xiàn)分開，并通過工廠模式封裝消息實(shí)現(xiàn)對象的創(chuàng)建，以達(dá)到松散耦合的目的。 由于在PetShop中僅對訂單的處理使用了異步處理方式，因此在消息接口IMessaging中，僅定義了一個IOrder接口，其類圖如下： 在對消息接口的實(shí)現(xiàn)中，考慮到未來的擴(kuò)展中會有其他的數(shù)據(jù)對象會使用MSMQ，因此定義了一個Queue的基類，實(shí)現(xiàn)消息Receive和Send的基本操作：public virtual object Receive(){ try { using (Message message = (timeout, transactionType)) return message。 } catch (MessageQueueException mqex) { if ( == ) throw new TimeoutException()。 throw。 }}public virtual void Send(object msg){ (msg, transactionType)。} ，作為存放數(shù)據(jù)的隊(duì)列。MSMQ隊(duì)列是一個可持久的隊(duì)列，因此不必?fù)?dān)心用戶不間斷地下訂單會導(dǎo)致訂單數(shù)據(jù)的丟失。在PetShopQueue設(shè)置了timeout值，OrderProcessor會根據(jù)timeout值定期掃描隊(duì)列中的訂單數(shù)據(jù)。 MSMQMessaging模塊中，Order對象實(shí)現(xiàn)了IMessaging模塊中定義的接口IOrder，同時它還繼承了基類PetShopQueue，其定義如下： public class Order:PetShopQueue, 方法的實(shí)現(xiàn)代碼如下： public new OrderInfo Receive() { // This method involves in distributed transaction and need Automatic Transaction type = 。 return (OrderInfo)((Message)()).Body。 } public OrderInfo Receive(int timeout) { = ((timeout))。 return Receive()。 } public void Send(OrderInfo orderMessage) { // This method does not involve in distributed transaction and optimizes performance using Single type = 。 (orderMessage)。 } 所以，最后的類圖應(yīng)該如下： 注意在Order類的Receive()方法中，是用new關(guān)鍵字而不是override關(guān)鍵字來重寫其父類PetShopQueue的Receive()虛方法。因此，如果是實(shí)例化如下的對象，將會調(diào)用PetShopQueue的Receive()方法，而不是子類Order的Receive()方法： PetShopQueue queue = new Order()。 ()。 從設(shè)計上來看，由于PetShop采用“面向接口設(shè)計”的原則，如果我們要創(chuàng)建Order對象，應(yīng)該采用如下的方式： IOrder order = new Order()。 ()。 考慮到IOrder的實(shí)現(xiàn)有可能的變化，PetShop仍然利用了工廠模式，將IOrder對象的創(chuàng)建用專門的工廠模塊進(jìn)行了封裝： 在類QueueAccess中，通過CreateOrder()方法利用反射技術(shù)創(chuàng)建正確的IOrder類型對象： public static CreateOrder() { string className = path + “.Order”。 return )(path).CreateInstance(className)。 } path的值通過配置文件獲取： private static readonly string path = [”O(jiān)rderMessaging”]。 而配置文件中，OrderMessaging的值設(shè)置如下： add key=”O(jiān)rderMessaging” value=””/ 之所以利用工廠模式來負(fù)責(zé)對象的創(chuàng)建，是便于在業(yè)務(wù)層中對其調(diào)用，例如在BLL模塊中OrderAsynchronous類：public class OrderAsynchronous : IOrderStrategy{ private static readonly asynchOrder = ()。 public void Insert( order){ (order)。 }} 一旦IOrder接口的實(shí)現(xiàn)發(fā)生變化，這種實(shí)現(xiàn)方式就可以使得客戶僅需要修改配置文件，而不需要修改代碼，如此就可以避免程序集的重新編譯和部署，使得系統(tǒng)能夠靈活應(yīng)對需求的改變。例如定義一個實(shí)現(xiàn)IOrder接口的SpecialOrder，則可以新增一個模塊，而類名則仍然為Order，那么此時我們僅需要修改配置文件中OrderMessaging的值即可： add key=”O(jiān)rderMessaging” value=””/ OrderProcessor是一個控制臺應(yīng)用程序，不過可以根據(jù)需求將其設(shè)計為Windows Service。它的目的就是接收消息隊(duì)列中的訂單數(shù)據(jù)，然后將其插入到Order和Inventory數(shù)據(jù)庫中。它利用了多線程技術(shù)，以達(dá)到提高系統(tǒng)性能的目的。 在OrderProcessor應(yīng)用程序中，主函數(shù)Main用于控制線程，而核心的執(zhí)行任務(wù)則由方法ProcessOrders()實(shí)現(xiàn)： private static void ProcessOrders() { // the transaction timeout should be long enough to handle all of orders in the batch TimeSpan tsTimeout = ((transactionTimeout * batchSize))。 Order order = new Order()。 while (true) { // queue timeout variables TimeSpan datetimeStarting = new TimeSpan()。 double elapsedTime = 0。 int processedItems = 0。 ArrayList queueOrders = new ArrayList()。