【正文】 的時(shí)間，其單位為秒。我們可以通過(guò)OutputCache指令完成對(duì)Web頁(yè)面的輸出緩存。當(dāng)用戶第二次查詢時(shí)，就可以省去數(shù)據(jù)查詢的過(guò)程，減少頁(yè)面的響應(yīng)時(shí)間。例如，在一個(gè)電子商務(wù)網(wǎng)站里，用戶需要經(jīng)常查詢商品信息，這個(gè)過(guò)程會(huì)涉及到數(shù)據(jù)庫(kù)訪問(wèn)以及搜索條件的匹配，在數(shù)據(jù)量較大的情況下，如此的搜索過(guò)程是較為耗時(shí)的。相對(duì)于應(yīng)用程序緩存而言，頁(yè)輸出緩存的應(yīng)用更為廣泛。與之對(duì)應(yīng)的是緩存中數(shù)據(jù)項(xiàng)的移除。我們還可以為應(yīng)用程序緩存添加依賴項(xiàng)，使得依賴項(xiàng)發(fā)生更改時(shí)，該數(shù)據(jù)項(xiàng)能夠從緩存中移除：string[] dependencies = {”Second”}。我們可以利用Add或Insert方法，將數(shù)據(jù)項(xiàng)添加到應(yīng)用程序緩存中，如下所示：Cache[”First”] = “First Item”。它是一個(gè)密封類，不能被繼承。此外，調(diào)用者還可以通過(guò)CacheItemRemovedCallback委托，定義回調(diào)方法使得數(shù)據(jù)項(xiàng)被移除時(shí)能夠通知用戶。放入在緩存中的數(shù)據(jù)對(duì)象其生命周期是受到限制的，即使在整個(gè)應(yīng)用程序的生命周期里，也不能保證該數(shù)據(jù)對(duì)象一直有效。應(yīng)用程序緩存其實(shí)現(xiàn)原理說(shuō)來(lái)平淡無(wú)奇。一種是應(yīng)用程序緩存，它允許開發(fā)者將程序生成的數(shù)據(jù)或報(bào)表業(yè)務(wù)對(duì)象放入緩存中。通過(guò)某種方法，將系統(tǒng)需要的數(shù)據(jù)對(duì)象、Web頁(yè)面存儲(chǔ)在內(nèi)存中，使得Web站點(diǎn)在需要獲取這些數(shù)據(jù)時(shí)，不需要經(jīng)過(guò)繁瑣的數(shù)據(jù)庫(kù)連接、查詢和復(fù)雜的邏輯運(yùn)算，就可以“觸手可及”，如“探囊取物”般容易而快速，從而提高整個(gè)Web系統(tǒng)的性能。軟件設(shè)計(jì)借鑒了硬件設(shè)計(jì)中引入緩存的機(jī)制以改善整個(gè)系統(tǒng)的性能，尤其是對(duì)于一個(gè)數(shù)據(jù)庫(kù)驅(qū)動(dòng)的Web應(yīng)用程序而言，緩存的利用是不可或缺的，畢竟，數(shù)據(jù)庫(kù)查詢可能是整個(gè)Web站點(diǎn)中調(diào)用最頻繁但同時(shí)又是執(zhí)行最緩慢的操作之一，我們不能被它老邁的雙腿拖緩我們前進(jìn)的征程。因?yàn)镃ache的存取速度比內(nèi)存快，因而引入Cache能夠有效的解決CPU與內(nèi)存之間的速度不匹配問(wèn)題。 Pattern — bruce zhang 6:20 pm 《解剖PetShop》系列之四四 如果對(duì)微型計(jì)算機(jī)硬件系統(tǒng)有足夠的了解，那么我們對(duì)于Cache這個(gè)名詞一定是耳熟能詳?shù)?。由于我們已?jīng)定義了統(tǒng)一的接口規(guī)范，在通過(guò)消息隊(duì)列形成文件后，此時(shí)的數(shù)據(jù)就已經(jīng)與平臺(tái)無(wú)關(guān)了，完成數(shù)據(jù)的處理。 首先Dealer的數(shù)據(jù)通過(guò)MSMQ傳遞到MSMQ Server，此時(shí)可以將數(shù)據(jù)插入到SQL Server數(shù)據(jù)庫(kù)中，同時(shí)利用FTP將數(shù)據(jù)傳送到專門的文件服務(wù)器上。 實(shí)現(xiàn)架構(gòu)如下：這里就涉及到兩個(gè)系統(tǒng)之間數(shù)據(jù)的傳遞。在為一個(gè)汽車制造商開發(fā)一個(gè)大型系統(tǒng)時(shí)，需要將數(shù)據(jù)傳遞到管理中心，并且該數(shù)據(jù)將被Oracle的EBS(EBusiness System)使用。 Microsoft Messaging Queue(MSMQ)技術(shù)除用于異步處理以外，它主要還是一種分布式處理技術(shù)。 因此，以異步方式插入訂單的流程如下圖所示： add key=”O(jiān)rderStrategyClass” value=”” / 由于OrderProcessor是一個(gè)單獨(dú)的應(yīng)用程序，因此它使用的配置文件與PetShop不同，在該文件中，對(duì)IOrderStategy的配置為： return ()(path).CreateInstance(className)。 // Look up which strategy to use from config file ，仍然利用配置文件來(lái)動(dòng)態(tài)創(chuàng)建IOrderStategy對(duì)象：private static readonly orderInsertStrategy = LoadInsertStrategy()。 在這里，運(yùn)用了一個(gè)策略模式，類圖如下所示： (order)。 // Call credit card procesor } } ()。 } totalOrdersProcessed++。 processedItems++。 ((OrderInfo)queueOrders[k])。 k++) for (int k = 0。 } //exit loop because no more messages are waiting catch (TimeoutException) //update elapsed time // exit loop { } ((queueTimeout))。 if ((elapsedTime + queueTimeout + transactionTimeout) ) { { j batchSize。 // Receive the orders from the queue using (TransactionScope ts = new TransactionScope(, tsTimeout)) ArrayList queueOrders = new ArrayList()。 int processedItems = 0。 double elapsedTime = 0。 TimeSpan datetimeStarting = new TimeSpan()。 { // the transaction timeout should be long enough to handle all of orders in the batch private static void ProcessOrders()它的目的就是接收消息隊(duì)列中的訂單數(shù)據(jù)，然后將其插入到Order和Inventory數(shù)據(jù)庫(kù)中。 add key=”O(jiān)rderMessaging” value=””/ 一旦IOrder接口的實(shí)現(xiàn)發(fā)生變化，這種實(shí)現(xiàn)方式就可以使得客戶僅需要修改配置文件，而不需要修改代碼，如此就可以避免程序集的重新編譯和部署，使得系統(tǒng)能夠靈活應(yīng)對(duì)需求的改變。 public void Insert( order){ private static readonly asynchOrder = ()。 之所以利用工廠模式來(lái)負(fù)責(zé)對(duì)象的創(chuàng)建，是便于在業(yè)務(wù)層中對(duì)其調(diào)用，例如在BLL模塊中OrderAsynchronous類：public class OrderAsynchronous : IOrderStrategy{ 而配置文件中，OrderMessaging的值設(shè)置如下： private static readonly string path = [”O(jiān)rderMessaging”]。 } return )(path).CreateInstance(className)。 string className = path + “.Order”。 public static CreateOrder() 從設(shè)計(jì)上來(lái)看，由于PetShop采用“面向接口設(shè)計(jì)”的原則，如果我們要?jiǎng)?chuàng)建Order對(duì)象，應(yīng)該采用如下的方式： ()。 PetShopQueue queue = new Order()。 注意在Order類的Receive()方法中，是用new關(guān)鍵字而不是override關(guān)鍵字來(lái)重寫其父類PetShopQueue的Receive()虛方法。 所以，最后的類圖應(yīng)該如下： // This method does not involve in distributed transaction and optimizes performance using Single type public void Send(OrderInfo orderMessage) { // This method involves in distributed transaction and need Automatic Transaction type public new OrderInfo Receive() public class Order:PetShopQueue, MSMQ隊(duì)列是一個(gè)可持久的隊(duì)列，因此不必?fù)?dān)心用戶不間斷地下訂單會(huì)導(dǎo)致訂單數(shù)據(jù)的丟失。} }}public virtual void Send(object msg){ throw。 throw new TimeoutException()。 if ( == ) } return message。 using (Message message = (timeout, transactionType)) 在對(duì)消息接口的實(shí)現(xiàn)中，考慮到未來(lái)的擴(kuò)展中會(huì)有其他的數(shù)據(jù)對(duì)象會(huì)使用MSMQ，因此定義了一個(gè)Queue的基類，實(shí)現(xiàn)消息Receive和Send的基本操作：public virtual object Receive(){ ，主要分為如下幾部分：消息接口IMessaging、消息工廠MessagingFactory、MSMQ實(shí)現(xiàn)MSMQMessaging以及數(shù)據(jù)后臺(tái)處理應(yīng)用程序OrderProcessor。 ，使用了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ù)中。而在軟件設(shè)計(jì)上，比較有用的方式是利用多線程與異步處理方式。 在前面我曾提到，分層式結(jié)構(gòu)設(shè)計(jì)可能會(huì)在一定程度上影響數(shù)據(jù)訪問(wèn)的性能，然而與它給設(shè)計(jì)人員帶來(lái)的好處相比，幾乎可以忽略。解決性能的瓶頸，除了對(duì)硬件系統(tǒng)進(jìn)行升級(jí)外，軟件設(shè)計(jì)的合理性尤為重要。 Pattern — bruce zhang 12:11 pm 《解剖PetShop》系列之三三、PetShop數(shù)據(jù)訪問(wèn)層之消息處理 }}通過(guò)ServiceLocator，將所有與配置文件相關(guān)的namespace值統(tǒng)一管理起來(lái)，這有利于各種動(dòng)態(tài)創(chuàng)建對(duì)象的管理和未來(lái)的維護(hù)。 return ()ServiceLocator. LocateDALOrderObject(”O(jiān)rder”)。{例如類DataAccess就可以簡(jiǎn)化為：public sealed class DataAccess{}return (orderStategyPath).CreateInstance(fullPath)。}public static object LocateOrderStrategyObject(string className)return (orderPath).CreateInstance(fullPath)。}public static object LocateDALOrderObject(string className)return (dalPath).CreateInstance(fullPath)。public static object LocateDALObject(string className)private static readonly string orderStategyPath = [”O(jiān)rderStrategyAssembly”]。也就是說(shuō)，我們可以為整個(gè)系統(tǒng)提供類似于“Service Locator”的實(shí)現(xiàn)：public static class ServiceLocator{ }}在PetShop中，這種依賴配置文件和反射創(chuàng)建對(duì)象的方式極其常見，包括IBLLStategy、CacheDependencyFactory等等。 return ()(orderPath).CreateInstance(className)。public static CreateOrder() private static readonly string orderPath = [”O(jiān)rdersDAL”]。 private static readonly string path = [”WebDAL”]。之所以能用這個(gè)類達(dá)到抽象工廠的目的，是因?yàn)榕渲梦募头瓷涞倪\(yùn)用，如下的代碼片斷所示：public sealed class DataAccess{那么，抽象工廠模式中的相關(guān)工廠就可以簡(jiǎn)化為一個(gè)工廠類了，所以我將這種模式稱之為“具有簡(jiǎn)單工廠特質(zhì)的抽象工廠模式”，其類圖如下：也就是說(shuō)，配置好具體的Factory對(duì)象的完整的類名?！耙蕾囎⑷搿钡墓δ芡ǔＪ怯脤ｉT的IoC容器提供的，在Java平臺(tái)下，這樣的容器包括Spring，PicoContainer等。修改代碼的這種行為顯然是不可接受的。但這樣的設(shè)計(jì)雖然已經(jīng)達(dá)到了“封裝變化”的目的，但在創(chuàng)建PetShopFactory對(duì)象時(shí)，仍不可避免的出現(xiàn)了具體的類SQLServerFactory，也即是說(shuō)，程序在這個(gè)層面上產(chǎn)生了與SQLServerFactory的強(qiáng)依賴。IOrder = ()。標(biāo)準(zhǔn)的抽象工廠模式類圖如下：也就是說(shuō)，創(chuàng)建的對(duì)象有多種類別，而每種類別又有不同的實(shí)現(xiàn)，這是典型的抽象工廠模式的應(yīng)用場(chǎng)景。留待我們的還有兩個(gè)問(wèn)題需要解決：數(shù)據(jù)