【正文】 以我將這種模式稱(chēng)之為“具有簡(jiǎn)單工廠特質(zhì)的抽象工廠模式”，其類(lèi)圖如下：DataAccess類(lèi)完全取代了前面創(chuàng)建的工廠類(lèi)體系，它是一個(gè)sealed類(lèi)，其中創(chuàng)建各種數(shù)據(jù)對(duì)象的方法，均為靜態(tài)方法。之所以能用這個(gè)類(lè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中，這種依賴(lài)配置文件和反射創(chuàng)建對(duì)象的方式極其常見(jiàn)，包括IBLLStategy、CacheDependencyFactory等等。這些實(shí)現(xiàn)邏輯散布于整個(gè)PetShop系統(tǒng)中，在我看來(lái)，是可以在此基礎(chǔ)上進(jìn)行重構(gòu)的。也就是說(shuō)，我們可以為整個(gè)系統(tǒng)提供類(lèi)似于“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)。}//……}那么和所謂“依賴(lài)注入”相關(guān)的代碼都可以利用ServiceLocator來(lái)完成。例如類(lèi)DataAccess就可以簡(jiǎn)化為：public sealed class DataAccess{public static CreateOrder(){ return ()ServiceLocator. LocateDALOrderObject(”O(jiān)rder”)。 }}通過(guò)ServiceLocator，將所有與配置文件相關(guān)的namespace值統(tǒng)一管理起來(lái)，這有利于各種動(dòng)態(tài)創(chuàng)建對(duì)象的管理和未來(lái)的維護(hù)。 PetShop數(shù)據(jù)訪問(wèn)層之消息處理PetShop數(shù)據(jù)訪問(wèn)層之消息處理Filed under: Design amp。 Pattern — bruce zhang @ 12:11 pm 《解剖PetShop》系列之三三、PetShop數(shù)據(jù)訪問(wèn)層之消息處理 在進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，除了對(duì)安全、事務(wù)等問(wèn)題給與足夠的重視外，性能也是一個(gè)不可避免的問(wèn)題所在，尤其是一個(gè)B/S結(jié)構(gòu)的軟件系統(tǒng)，必須充分地考慮訪問(wèn)量、數(shù)據(jù)流量、服務(wù)器負(fù)荷的問(wèn)題。解決性能的瓶頸，除了對(duì)硬件系統(tǒng)進(jìn)行升級(jí)外，軟件設(shè)計(jì)的合理性尤為重要。 在前面我曾提到，分層式結(jié)構(gòu)設(shè)計(jì)可能會(huì)在一定程度上影響數(shù)據(jù)訪問(wèn)的性能，然而與它給設(shè)計(jì)人員帶來(lái)的好處相比，幾乎可以忽略。要提供整個(gè)系統(tǒng)的性能，還可以從數(shù)據(jù)庫(kù)的優(yōu)化著手，例如連接池的使用、建立索引、優(yōu)化查詢(xún)策略等等，例如在PetShop中就利用了數(shù)據(jù)庫(kù)的Cache，對(duì)于數(shù)據(jù)量較大的訂單數(shù)據(jù)，則利用分庫(kù)的方式為其單獨(dú)建立了Order和Inventory數(shù)據(jù)庫(kù)。而在軟件設(shè)計(jì)上，比較有用的方式是利用多線程與異步處理方式。 ，使用了Microsoft Messaging Queue(MSMQ)技術(shù)來(lái)完成異步處理，利用消息隊(duì)列臨時(shí)存放要插入的數(shù)據(jù)，使得數(shù)據(jù)訪問(wèn)因?yàn)椴恍枰L問(wèn)數(shù)據(jù)庫(kù)從而提供了訪問(wèn)性能，至于隊(duì)列中的數(shù)據(jù)，則等待系統(tǒng)空閑的時(shí)候再進(jìn)行處理，將其最終插入到數(shù)據(jù)庫(kù)中。 ，主要分為如下幾部分：消息接口IMessaging、消息工廠MessagingFactory、MSMQ實(shí)現(xiàn)MSMQMessaging以及數(shù)據(jù)后臺(tái)處理應(yīng)用程序OrderProcessor。從模塊化分上，PetShop自始自終地履行了“面向接口設(shè)計(jì)”的原則，將消息處理的接口與實(shí)現(xiàn)分開(kāi)，并通過(guò)工廠模式封裝消息實(shí)現(xiàn)對(duì)象的創(chuàng)建，以達(dá)到松散耦合的目的。 由于在PetShop中僅對(duì)訂單的處理使用了異步處理方式，因此在消息接口IMessaging中，僅定義了一個(gè)IOrder接口，其類(lèi)圖如下： 在對(duì)消息接口的實(shí)現(xiàn)中，考慮到未來(lái)的擴(kuò)展中會(huì)有其他的數(shù)據(jù)對(duì)象會(huì)使用MSMQ，因此定義了一個(gè)Queue的基類(lèi)，實(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ì)列是一個(gè)可持久的隊(duì)列，因此不必?fù)?dān)心用戶(hù)不間斷地下訂單會(huì)導(dǎo)致訂單數(shù)據(jù)的丟失。在PetShopQueue設(shè)置了timeout值，OrderProcessor會(huì)根據(jù)timeout值定期掃描隊(duì)列中的訂單數(shù)據(jù)。 MSMQMessaging模塊中，Order對(duì)象實(shí)現(xiàn)了IMessaging模塊中定義的接口IOrder，同時(shí)它還繼承了基類(lèi)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)。 } 所以，最后的類(lèi)圖應(yīng)該如下： 注意在Order類(lèi)的Receive()方法中，是用new關(guān)鍵字而不是override關(guān)鍵字來(lái)重寫(xiě)其父類(lèi)PetShopQueue的Receive()虛方法。因此，如果是實(shí)例化如下的對(duì)象，將會(huì)調(diào)用PetShopQueue的Receive()方法，而不是子類(lèi)Order的Receive()方法： PetShopQueue queue = new Order()。 ()。 從設(shè)計(jì)上來(lái)看，由于PetShop采用“面向接口設(shè)計(jì)”的原則，如果我們要?jiǎng)?chuàng)建Order對(duì)象，應(yīng)該采用如下的方式： IOrder order = new Order()。 ()。 考慮到IOrder的實(shí)現(xiàn)有可能的變化，PetShop仍然利用了工廠模式，將IOrder對(duì)象的創(chuàng)建用專(zhuān)門(mén)的工廠模塊進(jìn)行了封裝： 在類(lèi)QueueAccess中，通過(guò)CreateOrder()方法利用反射技術(shù)創(chuàng)建正確的IOrder類(lèi)型對(duì)象： public static CreateOrder() { string className = path + “.Order”。 return )(path).CreateInstance(className)。 } path的值通過(guò)配置文件獲取： private static readonly string path = [”O(jiān)rderMessaging”]。 而配置文件中，OrderMessaging的值設(shè)置如下： add key=”O(jiān)rderMessaging” value=””/ 之所以利用工廠模式來(lái)負(fù)責(zé)對(duì)象的創(chuàng)建，是便于在業(yè)務(wù)層中對(duì)其調(diào)用，例如在BLL模塊中OrderAsynchronous類(lèi)：public class OrderAsynchronous : IOrderStrategy{ private static readonly asynchOrder = ()。 public void Insert( order){ (order)。 }} 一旦IOrder接口的實(shí)現(xiàn)發(fā)生變化，這種實(shí)現(xiàn)方式就可以使得客戶(hù)僅需要修改配置文件，而不需要修改代碼，如此就可以避免程序集的重新編譯和部署，使得系統(tǒng)能夠靈活應(yīng)對(duì)需求的改變。例如定義一個(gè)實(shí)現(xiàn)IOrder接口的SpecialOrder，則可以新增一個(gè)模塊，而類(lèi)名則仍然為Order，那么此時(shí)我們僅需要修改配置文件中OrderMessaging的值即可： add key=”O(jiān)rderMessaging” value=””/ OrderProcessor是一個(gè)控制臺(tái)應(yīng)用程序，不過(guò)可以根據(jù)需求將其設(shè)計(jì)為Windows Service。它的目的就是接收消息隊(duì)列中的訂單數(shù)據(jù)，然后將其插入到Order和Inventory數(shù)據(jù)庫(kù)中。它利用了多線程技術(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()。