緩存集成
在 ASP.NET 中構建和使用自定義的 OutputCache 提供程序
下載代碼示例git
若是您是一位 Web 開發人員,您過去可能使用過 ASP.NET 提供的輸出緩存功能。 ASP.NET 輸出緩存功能是隨着 Microsoft .NET Framework 的第一個版本推出的,該功能經過從緩存中檢索向站點訪問者提供的內容以及避免從新執行頁面或控制器,提升了向站點訪問者提供內容方面的性能。 當返回您不常常更新的數據或者返回一段時間後將過時的數據時,該功能不須要您的應用程序執行耗費大量資源的數據庫調用操做。github
ASP.NET 輸出緩存使用的是內存存儲機制,而且在 NET Framework 4 出現以前,您沒法使用您本身的實現覆蓋或替代默認緩存。 如今,藉助新的 OutputCacheProvider 類型,您能夠在 ASP.NET 中實現您本身的緩存頁面輸出機制。web
在本文中,我將爲您介紹兩種自定義機制。 首先,我將使用 MongoDB(一種經常使用的面向文檔數據庫)在一個簡單的 ASP.NET MVC 應用程序中建立我本身的提供程序,以方便輸出緩存。 而後,我會使用同一個應用程序快速交換個人自定義提供程序,以便利用 Windows Azure AppFabric 的功能 — 具體地說,就是在雲中利用 Windows Azure 基礎結構提供分佈式內存緩存的新 DistributedCache 提供程序。mongodb
ASP.NET 中的輸出緩存
在 ASP.NET Web 窗體應用程序中,能夠經過向任意 ASP.NET 頁面或用戶控件添加 OutputCache Page 指令來配置輸出緩存:數據庫
-
- <%@ OutputCache Duration="60" Location="Any" VaryByParam="name" %>
-
對於 ASP.NET MVC 應用程序,輸出緩存是使用 ASP.NET MVC 附帶的操做篩選器來提供的,該操做篩選器可用做任何控制器操做的一個屬性:編程
-
- [OutputCache(Duration=60, VaryByParam="none")]
-
「Duration」和「VaryByParam」在 ASP.NET MVC 1 和 2 應用程序中是必需的(VaryByParam 在 ASP.NET MVC 3 中是可選的),這兩種機制都提供其餘一些屬性和參數,這些屬性和參數使開發人員可以控制緩存內容的方式(一些 VaryByX 參數)、緩存內容的位置 (Location) 和用於設置緩存無效依賴項的功能 (SqlDependency)。windows
對於傳統的輸出緩存,在您的應用程序中實現該功能時不須要任何其餘東西。 OutputCache 類型是一個在您的應用程序啓動時運行,並在遇到頁面指令或操做篩選器時開始發揮做用的 HttpModule。 收到第一個相關的頁面或控制器請求後,ASP.NET 將接收生成的內容(HTML、CSS、JavaScript 文件等)並將各個項目以及過時日期和用於標識相應項目的關鍵字放入內存緩存中。 過時日期由 Duration 屬性肯定,關鍵字則由到頁面的路徑和必要的 VaryBy 值的組合肯定 — 例如,若是提供了 VaryByParam 屬性,則會查詢字符串或參數值。 如今,請考慮一下以這種方式定義的控制器操做:瀏覽器
-
- [OutputCache(Duration=20, VaryByParam="vendorState")]
- Public ActionResult GetVendorList(string vendorState)
- {
- // Action logic here.
- }
-
在這種狀況下,對於 vendorState 的各個實例(例如,一個針對德克薩斯州,一個針對華盛頓州等等),ASP.NET 將在請求該州時分別緩存生成的 HTML 視圖的一個實例。 在這種狀況下,存儲各個實例所使用的關鍵字將是相關路徑和 vendorState 的組合。緩存
另外一方面,若是將 VaryByParam 屬性設置爲「none」,則 ASP.NET 將緩存第一次執行 GetVendorList 的結果,而且會向全部後續請求傳遞相同的緩存版本,而不考慮 vendorState 參數的值是否傳入了相應操做。 當沒有提供 VaryByParam 值時存儲此實例所使用的關鍵字就是路徑。 圖 1 簡單描述了此過程。服務器

圖 1 ASP.NET 輸出緩存過程
除了用於控制緩存中的項目的生存期的 Duration 參數之外,還有一些 VaryBy 參數(VaryByParam、VaryByHeader、VaryByCustom、VaryByControl 和 VaryByContentEncoding)用於控制緩存項目的精度,能夠配置輸出緩存,以控制緩存內容的位置(客戶端、服務器或下游代理服務器)。 此外,ASP.NET 2.0 引入了一個 SqlDependency 屬性,該屬性容許開發人員指定頁面或控件所依賴的數據庫表,所以,除了在時間上過時之外,您的基礎源數據的更新也可能會致使緩存項目過時。
儘管 .NET Framework 2.0 和 3.0 向默認緩存提供程序中引入了一些加強功能,可是提供程序自己仍然沒有改變:它仍然是一種內存存儲,並無用於爲您提供您本身的實現的擴展點或方法。 在大多數狀況下,內存緩存是一種徹底能夠接受的方法,但有時候,當服務器資源透支且內存不足時,它也會削弱站點性能。 此外,當內存確實不足時,會致使開發人員沒法有效地控制管理緩存資源的方式,從而致使默認緩存提供程序機制自動棄用緩存的資源(不考慮指定的持續時間)。
ASP.NET 中可擴展的輸出緩存
.NET Framework 4 引入了一種新功能,該功能使開發人員可以建立他們本身的輸出緩存提供程序,而且只需對新的或現有的應用程序及其配置做少許更改,即可輕鬆地將這些提供程序插入其中。 不管他們選擇的緩存信息使用的是哪一種存儲機制(例如,本地磁盤、相關和非相關數據庫、雲,甚至是分佈式緩存引擎(如 Windows Server AppFabric 中所提供的)),均可以隨意使用這些提供程序。 甚至還能夠針對相同應用程序中的不一樣頁面使用多個提供程序。
與建立派生自新的 System.Web.Caching.OutputCacheProvider 抽象類的新類以及覆蓋 ASP.NET 使用緩存項目所需的四種方法同樣,建立您本身的輸出緩存提供程序也很簡單。 下面列出了 OutputCacheProvider 類的框架定義(請參見 bit.ly/fozTLc 以瞭解更多信息):
-
- public abstract class OutputCacheProvider : ProviderBase
- {
- public abstract object Get(string key);
- public abstract object Add(string key, object entry, DateTime utcExpiry);
- public abstract void Set(string key, object entry, DateTime utcExpiry);
- public abstract void Remove(string key);
- }
-
實現了這四種方法後,接下來要作的就是向您的 web.config 添加新提供程序,將其指定爲默認提供程序,並向您的應用程序添加一個 OutputCache 指令或屬性。 我會在介紹如何建立咱們本身的輸出緩存提供程序(使用一個叫作 MongoDB 的文檔數據庫)時詳細說明這些步驟。 首先,我要介紹一些關於在構建自定義提供程序時使用的工具的背景信息,這可能對你們有所幫助。
NoSQL、文檔數據庫和 MongoDB
在過去的數十年中,首選應用程序存儲機制一直都是關係數據庫管理系統 (RDBMS),該系統在表中存儲數據和關係。 SQL Server 和 Oracle 都屬於 RDBMS,它們也是目前最受歡迎的商業和開源數據庫。
然而,並不是全部須要存儲的問題都適合相同的事務建模。 二十世紀九十年代末,隨着 Internet 的擴展,許多站點都擴大了規模以便託管大量數據,很明顯,關係模型在某些類型的數據密集型應用程序上的性能差強人意。 例如,索引大量文檔、在高流量站點上向消費者傳遞網頁或向其傳遞流媒體。
許多公司經過轉而使用 NoSQL 數據庫解決了他們不斷增長的存儲需求,NoSQL 數據庫是一種不公開 SQL 接口、固定架構或預約義關係的輕型數據庫。 NoSQL 數據庫獲得了企業(例如 Google Inc. (BigTable)、Amazon.com Inc. (Dynamo) 和 Facebook(其收件箱搜索的存儲量超過了 50TB))的普遍使用,而且在普及性和使用方面實現了穩定增加。
值得注意的是,雖然有些人將 NoSQL 這個詞用做了呼籲停用全部 RDBMS 的口號,但另一些人則強調同時利用這兩類存儲的價值。 人們構建 NoSQL 數據庫的目的是解決 RDBMS 沒法解決的一類問題,而不是要用它完全代替這些系統。 有辨別能力的開發人員應該會清楚地瞭解這兩種系統,並根據具體狀況來利用相應的系統,有時甚至會在一個應用程序中混合使用這兩種類型的存儲。
很是適合使用 NoSQL 數據庫的一種狀況就是輸出緩存。 NoSQL 數據庫對於使用瞬態數據或臨時數據來講是理想之選,而從 ASP.NET 應用程序緩存的頁面固然符合要求。 MongoDB (mongodb.org) 是一個經常使用的 NoSQL 選項,Shutterfly、Foursquare、《紐約時報》等許多公司都在使用這種面向文檔的 NoSQL 數據庫。MongoDB 是一個以 C++ 編寫的徹底開放的源數據庫,該數據庫具備面向幾乎全部主要編程語言(包括 C#)的驅動程序。 咱們將會把 MongoDB 用做咱們的自定義輸出緩存提供程序的存儲機制。
使用 MongoDB 構建自定義的 OutputCacheProvider
要開始使用該工具,您須要登陸 mongodb.org 下載和安裝該工具。mongodb.org/display/DOCS/Quickstart 上提供的文檔中包含了在 Windows、Mac OS X 和 Unix 上安裝 MongoDB 時所需瞭解的全部信息。 下載 MongoDB 並使用外殼程序完成測試後,我建議您使用安裝目錄中的如下命令來將該數據庫做爲一項服務進行安裝(請務必以管理員身份運行 cmd.exe):
C:\Tools\MongoDB\bin>mongod.exe --logpath C:\Tools\MongoDB\Logs --directoryperdb --install
MongoDB 將做爲一項服務自行安裝到您的計算機上,並將使用 C:\Data\db 做爲其全部數據庫的默認目錄。經過 diretoryperdb 選項可以讓 MongoDB 爲您建立的每一個數據庫建立根目錄。
運行前一個命令以後,鍵入如下內容以啓動服務:
啓動並運行 MongoDB 後,您須要在 .NET 中安裝一個驅動程序庫以使用 MongoDB。 有幾個選項可供使用;我將使用 Sam Corder 建立的 mongodb-csharp 驅動程序 (github.com/samus/mongodb-csharp)。
咱們安裝了 MongoDB,而且在 .NET 應用程序中有一個可使用的驅動程序,所以如今是時候建立自定義的輸出緩存提供程序了。 爲了執行這項操做,我建立了一個叫作 DocumentCache 的新類庫,並添加了兩個類:DocumentDatabaseOutputCacheProvider 和 CacheItem。
第一個是個人提供程序,它是一個可對抽象 OutputCacheProvider 進行子類化的公共類。 開始的實現過程如圖 2 所示。
圖 2 起始 OutputCacheProvider 類
-
- public class DocumentDatabaseOutputCacheProvider : OutputCacheProvider
- {
- readonly Mongo _mongo;
- readonly IMongoCollection<CacheItem> _cacheItems;
-
- public override object Get(string key)
- {
- return null;
- }
-
- public override object Add(string key, object entry, DateTime utcExpiry)
- {
- return null;
- }
-
- public override void Set(string key, object entry, DateTime utcExpiry)
- {
- return;
- }
-
- public override void Remove(string key)
- {
- return;
- }
- }
-
請注意,圖 2 中的第二個私有變量是指 CacheItem,即我須要在個人項目中建立的另外一個類。 CacheItem 的做用是包含個人輸出緩存提供程序與 ASP.NET 和個人數據庫協同工做所需的相關詳細信息,不過它不是個人提供程序所需的外部對象。 所以,我將 CacheItem 定義爲內部類,以下所示:
-
- [Serializable]
- internal class CacheItem
- {
- public string Id { get; set; }
- public byte[] Item { get; set; }
- public DateTime Expiration { get; set; }
- }
-
Id 映射到 ASP.NET 向我提供的關鍵字。 您會想到這個關鍵字是路徑和在您的頁面指令或操做屬性中定義的任何 VaryBy 條件的組合。 Expiration 字段對應於 Duration 參數,而 Item 屬性是要緩存的項目。
咱們將經過在 DocumentDatabaseOutputCacheProvider 類的構造函數中進行一些設置來開始實現咱們的提供程序。 因爲咱們知道 ASP.NET 在應用程序的整個生存期內僅保留提供程序的一個實例,所以,咱們能夠在構造函數中進行一些設置,以下所示:
-
- readonly Mongo _mongo;
- readonly IMongoCollection<CacheItem> _cacheItems;
-
- public DocumentDatabaseOutputCacheProvider()
- {
- _mongo = new Mongo();
- _mongo.Connect();
-
- var store = _mongo.GetDatabase("OutputCacheDB");
- _cacheItems = store.GetCollection<CacheItem>();
- }
-
構造函數建立一個 Mongo 類型的新實例,並使用默認位置 (localhost) 鏈接到服務器。 以後,它向 MongoDB 請求 OutputCacheDB 數據庫以及一個 CacheItem 類型的 IMongoCollection。 因爲 MongoDB 是一個架構靈活的數據庫,所以支持動態建立數據庫。 第一次調用 _mongo.GetDatabase(「OutputCacheDB」) 將返回新數據庫的一個實例,當第一次插入發生時,便會在磁盤上建立該數據庫。
如今,讓咱們實現 Add 方法,如圖 3 所示。
圖 3 實現 Add 方法
-
- public override object Add(string key, object entry, DateTime utcExpiry)
- {
- key = MD5(key);
- var item = _cacheItems.FindOne(new { _id = key });
- if (item != null) {
- if (item.Expiration.ToUniversalTime() <= DateTime.UtcNow) {
- _cacheItems.Remove(item);
- } else {
- return Deserialize(item.Item);
- }
- }
-
- _cacheItems.Insert(new CacheItem
- {
- Id = key,
- Item = Serialize(entry),
- Expiration = utcExpiry
- });
-
- return entry
- }
-
我在各個方法中執行的第一個操做就是對傳入的關鍵字調用 MD5 方法。 此方法(爲了保持簡潔,此處未做詳細說明,但您能夠從在線源代碼下載部分中進行查看)生成基於 ASP.NET 向我提供的關鍵字的、數據庫能夠識別的 MD5 哈希。 而後,我調用個人 IMongoCollection<CacheItem> 類型 _cacheItems,以便在底層數據庫中查詢那個關鍵字。 請注意傳入 FindOne 方法中的匿名類型 (new { _id = key})。 查詢 MongoDB 主要是經過選擇器對象或在文檔中指定一個或多個字段以便在數據庫中進行匹配的模板文檔來完成的。 _id 是 MongoDB 用於存儲文檔的關鍵字,而按照我所使用的驅動程序的約定,該屬性會自動映射到個人 CacheItem 類的 Id 屬性。 所以,當我保存新的緩存項時,正如您在圖 3 中所示的 _cacheItems.Insert 方法中看到的,關鍵字是使用 Id 屬性進行分配的,MongoDB 使用該屬性填充記錄的內部 _id 字段。 MongoDB 是一種關鍵字值存儲,所以各個 CacheItem 對象都是使用二進制序列化的 JSON 進行存儲的,以下所示:
-
- { "_id" : ObjectId(Id), "CacheItem": new CacheItem { Id = key, Item = entry, Expiration = utcExpiry } }
-
若是我發現一個 CacheItem 具備與傳入的關鍵字相同的關鍵字,則我會根據當前的 UTC 時間來檢查該項目是否過時。 若是該項目還沒有過時,則我會利用私有方法(可在在線源代碼部分中找到該方法)對它進行二進制反序列化,並返回現有項目。 此外,我向個人存儲中插入一個新項目,對其進行二進制序列化,並返回傳入的條目。
向緩存中添加了項目後,我即可以添加 Get 方法,該方法將根據關鍵字查找並返回一個緩存項(若是找不到結果,則返回 null),如圖 4 所示。
圖 4 實現 Get 方法
-
- public override object Get(string key)
- {
- key = MD5(key);
- var cacheItem = _cacheItems.FindOne(new { _id = key });
-
- if (cacheItem != null) {
- if (cacheItem.Expiration.ToUniversalTime() <= DateTime.UtcNow) {
- _cacheItems.Remove(cacheItem);
- } else {
- return Deserialize(cacheItem.Item);
- }
- }
-
- return null;
- }
-
與 Add 方法同樣,Get 方法也會檢查數據庫中存在的項目是否過時,若是項目已通過期,則會將其刪除並返回 null。 若是存在的項目還沒有過時,則會返回該項目。
如今,讓咱們來實現 Remove 方法,該方法可接受一個關鍵字並從數據庫中刪除與該關鍵字相匹配的項目,以下所示:
-
- public override void Remove(string key)
- {
- key = MD5(key);
- _cacheItems.Remove(new { _id = key });
- }
-
正如咱們的驅動程序爲了得到尚不存在的數據庫而使用的代碼同樣,若是咱們嘗試刪除數據庫中不存在的項目,MongoDB 不會報錯。 它不會執行任何操做。
根據咱們的抽象基類,咱們仍須要實現最後一個方法 — Set 方法來得到一個功能性自定義輸出緩存提供程序。 我已在圖 5 中使用了該方法。
圖 5 實現 Set 方法 Public Override Void Set(string key, object entry, DateTime utcExpiry)
-
- {
- key = MD5(key);
- var item = _cacheItems.FindOne(new { _id = key });
-
- if (item != null)
- {
- item.Item = Serialize(entry);
- item.Expiration = utcExpiry;
- _cacheItems.Save(item);
- }
- else
- {
- _cacheItems.Insert(new CacheItem
- {
- Id = key,
- Item = Serialize(entry),
- Expiration = utcExpiry
- });
- }
- }
-
整體來看,Add 方法彷佛與 Set 方法是相同的,但它們的預期實現之間卻存在重要區別。 根據關於 OutputCacheProvider 類的 MSDN 庫文檔 (bit.ly/fozTLc),自定義提供程序的 Add 方法應在緩存中查找與指定關鍵字匹配的值,若是存在這樣的值,則不對緩存執行任何操做並返回保存的項目。 若是不存在該項目,Add 應插入該項目。
另外一方面,Set 方法應始終將其值保存在緩存中,若是不存在該項目,則插入該項目,若是存在,則覆蓋該項目。 在關於 Add 的圖 3 和關於 Set 的圖 5 中,您會注意到,這兩種方法都是按指定方式執行的。
實現這四種方法後,如今咱們能夠運行咱們的提供程序了。
在 ASP.NET MVC 中使用 MongoDB OutputCacheProvider
編譯完咱們的自定義提供程序後,咱們能夠經過幾行配置將此提供程序添加到任何 ASP.NET 應用程序中。添加對包含此提供程序的程序集的引用後,將如下文本添加到您的 web.config 文件的 <system.web> 部分:
<caching> <outputCache defaultProvider="DocumentDBCache"> <providers> <add name="DocumentDBCache" type="DocumentCache.DocumentDatabaseOutputCacheProvider, DocumentCache" /> </providers> </outputCache> </caching>
<providers> 元素定義您想添加到應用程序中的全部自定義提供程序,併爲每一個提供程序定義名稱和類型。因爲您能夠在一個應用程序中包含多個自定義提供程序,所以您還但願指定 defaultProvider 屬性,如我在以前的代碼段中的操做同樣。
個人示例應用程序是一個帶有 CustomersController 的簡單 ASP.NET MVC 站點。 該控制器中有一個稱爲 TopCustomers 的操做,它返回個人業務的頂級客戶列表。 此信息通過複雜計算並在個人 SQL Server 數據庫中進行屢次數據庫查詢得出,且每小時僅更新一次。 所以,它是緩存的理想候選項。 因此,我在個人操做中添加了一個 OutputCache 屬性,以下所示:
-
- [OutputCache(Duration = 3600, VaryByParam = "none")]
- public ActionResult TopCustomers()
- {
- var topCustomers = _repository.GetTopCustomers();
- return View(topCustomers);
- }
-
如今,若是我運行站點並導航到個人 TopCustomers 頁面,那麼個人自定義提供程序便會執行。 首先,將調用個人 Get 方法,可是因爲此頁面還未緩存,所以不會返回任何內容。 接下來,控制器操做將執行並返回 TopCustomers 視圖,如圖 6 所示。

圖 6 緩存的 TopCustomers 視圖
以後,ASP.NET 將調用個人自定義緩存提供程序,執行 Set 方法,項目隨即被緩存。 我已將持續時間設置爲 3,600 秒(即 60 分鐘),該時間段內的每一個後續請求都將使用個人 Get 方法返回的緩存項,避免從新執行個人控制器操做。 若是任何基礎數據發生了更改,那麼到期後第一次執行時將顯示更新內容,以後,新信息將被緩存一小時。 若是您想查看運行中的 MongoDB,您有兩種選擇。 您能夠打開您的瀏覽器,導航到 http://localhost:28107/,它顯示了日誌和有關您數據庫的最近查詢和統計信息。 或者,您也能夠運行 MongoDB 安裝路徑的 bin 目錄下的 mongo.exe,而後經過 Mongo Shell 查詢您的數據庫。 有關使用這些工具的更多信息,請查看 mongodb.org。
使用 DistributedCache 提供程序
若是到目前爲止我介紹的全部內容已經超出了您想了解的內容的深度和廣度,怎麼辦呢? 也許您想換用一種緩存機制,可是您是否是既沒有時間建立本身的緩存機制,也不但願用本身的緩存機制呢? 您將很高興地看到,自從推出可擴展的輸出緩存以來,目前已有多種不一樣的緩存機制(由 Microsoft 提供的、商業化的、開源的)可供使用或正處於開發階段。 其中一個例子就是基於雲的分佈式內存緩存:當前,DistributedCache 提供程序是做爲 Windows Azure AppFabric 的一部分提供的。 若是您已開始構建基於雲的應用程序,Windows Azure AppFabric Caching 能夠提升對這些應用程序數據的訪問速度,由於緩存是做爲雲服務提供的,設置很是簡單且維護方面不須要任何開銷。
目前,AppFabric Caching 是 Windows Azure AppFabric 社區技術預覽 10 月發行版本的一部分,所以沒有活動的 Windows Azure 賬戶,您也能夠訪問緩存功能。 可是,若是您是 MSDN 訂戶,我強烈建議您在windows.azure.com 上激活您的 Windows Azure 權益。 訪問 portal.appfabriclabs.com 並建立一個賬戶,以使用開發人員預覽功能。
建立 Labs 賬戶後,單擊「添加服務命名空間」連接,以啓用 AppFabric 服務(請參見圖 7)。

圖 7 Windows Azure AppFabric Labs 摘要頁面
設置服務命名空間後,單擊「緩存」連接,記下緩存部分列出的服務 URL 和身份驗證令牌(請參見圖 8)。 您須要使用這些信息配置您的應用程序來使用 DistributedCache 提供程序。

圖 8 AppFabric Labs 緩存設置頁面
接下來,您須要下載並安裝 Windows Azure AppFabric SDK(單擊門戶中「緩存」頁面上的下載連接)。 安裝完成後,您就能夠爲應用程序配置 Windows Azure AppFabric Caching 了。
您須要添加對安裝 SDK 時放置在您計算機中的多個程序集的引用。 使用您爲您的自定義文檔數據庫緩存使用的同一 ASP.NET MVC 應用程序,導航到 SDK 安裝位置(默認狀況下是 C:\Program Files*\Windows Azure AppFabric SDK\V2.0\Assemblies\Cache),而後添加對其中包含的每一個程序集的引用。
完成後,打開您的 web.config 並添加如下 <configSections> 條目,同時保留任何現有的配置部分:
<configSections> <section name="dataCacheClient" type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere"/> </configSections>
接下來,建立 <dataCacheClient> 部分,使用您的門戶賬戶中的詳細信息替換 <host> 名稱、cachePort 和 <messageSecurity> authorizationInfo 屬性,以下所示:
<dataCacheClient deployment="Simple"> <hosts> <host name="yournamespace.cache.appfabriclabs.com" cachePort="your port" /> </hosts> <securityProperties mode="Message"> <messageSecurity authorizationInfo="your authentication token"> </messageSecurity> </securityProperties> </dataCacheClient>
而後,在 <system.web> 下查找 <caching> 部分,並在您爲自定義提供程序建立的條目後添加如下提供程序條目:
<add name="DistributedCache" type="Microsoft.Web.DistributedCache.DistributedCacheOutputCacheProvider, Microsoft.Web.DistributedCache" cacheName="default" />
最後,將 <outputCache> 元素中的 defaultProvider 屬性更改成「DistributedCache」。DistributedCacheOutputCacheProvider 是抽象 OutputCacheProvider 的子類類型,正如咱們的 MongoDB 實現同樣。 如今,構建並運行您的應用程序,而後導航到「頂級客戶」頁面。 嘗試在列表仍處於緩存狀態時添加客戶,請注意,正如咱們的 MongoDB 實現同樣,列表將根據您指定的時間保持緩存狀態。
總結
在本文中,我介紹了 ASP.NET 輸出緩存(默認內存緩存的典型用法),以及使用 .NET Framework 4 中的 OutputCacheProvider 抽象類提供的新的可擴展緩存功能。 我談到了 NoSQL 和文檔數據庫,以及這些類型的系統對於使用瞬態數據(如緩存的輸出)來講有多麼理想。 我使用 MongoDB 構建了一個示例輸出緩存,並在 ASP.NET MVC 應用程序中使用了該緩存。 最後,我將輸出緩存移動到了雲中,通過簡單的設置和配置而不須要更改代碼,便交換出了咱們應用程序中的緩存機制。
可擴展的輸出緩存只是 ASP.NET 4 中衆多強大的新功能中的一項,我但願對此功能(以及可與此功能一塊兒使用的技術)的這種探索可以給你們帶來幫助。 要了解有關 MongoDB 的更多信息,請訪問 mongodb.org。要了解有關 Windows Azure AppFabric 的更多信息,請訪問portal.appfabriclabs.com/helpandresources.aspx。
Brandon Satrom 是 Microsoft 在德克薩斯州奧斯汀市的開發推廣人員。他的博客網址是userinexperience.com,您還能夠經過如下 Twitter 地址與他取得聯繫:@BrandonSatrom。
衷心感謝如下技術專家對本文的審閱:Brian H. Prince 和 Clark Sell