Asp.Net中的缓存机制的应用方式（一）：页面端缓存

最近在重温PetShop的一些代码，本来想记录一些阅读心得，但想想这个范例程序肯定被大家都研究烂了，肯定已经有前辈高人已经记录了详细的阅读心得，所以就去搜了一下，后来果然找到了一篇写得非常详细的阅读心得，也就偷懒作为收藏了，但我下面要介绍的是阅读了PetShop和部分高手对代码的分析文章后，单独就Cache部分的应用写一点自己的心得。
ASP.NET提供了两种基本的缓存机制来提供缓存功能。一种是应用程序缓存，它允许开发者将程序生成的数据或报表业务对象放入缓存中。另外一种缓存机制是页输出缓存，利用它，可以直接获取存放在缓存中的页面，而不需要经过繁杂的对该页面的再次处理。应用程序缓存涉及到后台代码的操作，我们放在后面讲，我们先来看看被广泛使用的相对简单的液输出缓存：

页输出缓存
页输出缓存可以通过内存将处理后的ASP.NET页面存储起来，当客户端再一次访问该页面时，可以省去页面处理的过程，从而提高页面访问的性能，以及Web服务器的吞吐量。例如，在一个电子商务网站里，用户需要经常查询商品信息，这个过程会涉及到数据库访问以及搜索条件的匹配，在数据量较大的情况下，如此的搜索过程是较为耗时的。此时，利用页输出缓存就可以将第一次搜索得到的查询结果页存储在缓存中。当用户第二次查询时，就可以省去数据查询的过程，减少页面的响应时间。
页输出缓存分为整页缓存和部分页缓存，按照我的理解，部分缓存也就是利用了ASP.Net用户控件的缓存机制所达到的效果，其缓存机理和代码方式都非常类似于整页缓存，所以这里只介绍整页缓存的方式。
我们可以通过@OutputCache指令完成对Web页面的输出缓存，这里主要涉及到两类参数：

1. Duration：该参数用于设置页面或控件进行缓存的时间，其单位为秒，比如这段代码：
   <%@ OutputCache Duration=“60“ VaryByParam=“none“ %>
   这里表明缓存时间为60秒。这是一个必填的属性，这个属性界定了缓存过期的一个基本事件，如果没有外界的干扰，该缓存将会在该时间到期后被自动从内存中移除。
2. 上面提到了缓存过期，它除了受到上面指定的Duration参数所规定的时间的影响外，还有我提到的外界因素的影响，而且这个外界因素还不止一个，分别用下面几个参数来界定：
   a. VaryByParam：这是一个必填参数，表示GET或 POST 名称/值对的字符串。这里所说的Get方式就是通过URL传递的参数，Post方式的参数在ASP.Net中一般要通过Server.Transfer方式传递。这种方式的一个基本运用还是通过监测Get参数的方式来判断是否发生变化和是否强制缓存过期。比如我们在一个项目信息首页中，项目信息根据URL中的ProjectId参数进行信息导入，如果该参数的Id相同，一般在短时间内，其项目信息也是不发生改变的，这个时候，我们就可以采用该参数指定ProjectId作为参数值，如下所示：
   <%@ OutputCache Duration="60" VaryByParam="ProjectId" %>
   Asp.Net缓存机制将会负责监视这个值的变化情况，如果该值没有发生变化，且又没有到缓存的过期时间，页面将从缓存中获取，只有在ProjectId值发生变化的时候，系统才会移除原有的缓存，再缓存一个新的版本。如果不使用该属性，可是设置为none。
   b.VaryByControl：这和VaryByParam参数二者必填其一，该参数指定了ASP.Net缓存机制需要监控的控件名称，，监控的原理类似于上面VaryByParam参数对Get参数的监控方式，只是这里的监控对象变成了控件的值，比如TextBox的Text属性，或者DropDownList的SelectedValue等，这里的测试非常简单，在页面上放置一个DropDownList控件，ID为1ropDownList1，在下面放置一个按钮，然后放置一个用于显示时间的Label控件，同时在页头上面设置如下代码：
   <%@ OutputCache Duration="60“ VaryByControl="dropDownList1" %>
   当我们改变了dropDownList1的选项，再按那个按钮的时候，Label中的时间就会发生改变，如果不改变选项，你单按按钮，在过期时间范围内，时间显示也是不会改变的，这说明这里的缓存过期监控确实起到了作用。
   c.VaryByCustom：这是一种允许自定义的缓存监控方式，非常的实用，他允许我们用代码的方式控制缓存的监控，是对上面两种方式的一种有益的补充。比如我们来想象一下这种情况，我们要给一个用户信息显示用户控件添加缓存监控，要求在用户切换的时候使缓存过期，在同一个登录用户访问的时候，启用缓存数据，这里的用户登录信息既不是存放在URL参数之中，有没有存放在页面的某一个控件之中，所以采用VaryByParam和VaryByControl的方式都无法满足要求，ASP.Net缓存监控机制考虑到了类似的复杂要求，提供这样的一种自定义的方式，我们可以看一下如何操作：
   首先，我们要在页头中表明如下代码：
   <%@ OutputCache Duration="15" VaryByParam="None" VaryByCustom="UserID" %>
   上面VaryByParam参数是必须的，这里设置成了None，以便启动VaryByCustom参数。VaryByCustom参数中定义了“UserID”这个值，这个值其实是作为后台的一个Override函数的一个参数，这个函数要求写在Global.asax文件中，如下面的代码所示：

 

Code
public override string GetVaryByCustomString(HttpContext context, string arg)
    {
        string cacheKey = "";
        switch (arg)
        {
            case "CategoryPageKey":
                if (Request.IsAuthenticated == true)
                {
                    cacheKey = "QQQ" + context.Request.QueryString["category_id"] + context.Request.QueryString["requestedPage"];
                }
                else
                {
                    cacheKey = "AAA" + context.Request.QueryString["category_id"] + context.Request.QueryString["requestedPage"];
                }
                break;
            case "SearchPageKey":
                if (Request.IsAuthenticated == true)
                {
                    cacheKey = "QQQ" + context.Request.QueryString["search_text"] + context.Request.QueryString["requestedPage"];
                }
                else
                {
                    cacheKey = "AAA" + context.Request.QueryString["search_text"] + context.Request.QueryString["requestedPage"];
                }
                break;
            case "ProductPageKey":
                if (Request.IsAuthenticated == true)
                {
                    cacheKey = "QQQ" + context.Request.QueryString["name"] + context.Request.QueryString["product_id"] + context.Request.QueryString["requestedPage"];
                }
                else
                {
                    cacheKey = "AAA" + context.Request.QueryString["name"] + context.Request.QueryString["product_id"] + context.Request.QueryString["requestedPage"];
                }
                break;
            case "ProductDetailsPageKey":
                if (Request.IsAuthenticated == true)
                {
                    cacheKey = "QQQ" + context.Request.QueryString["item_id"] + context.Request.QueryString["requestedPage"];
                }
                else
                {
                    cacheKey = "AAA" + context.Request.QueryString["item_id"] + context.Request.QueryString["requestedPage"];
                }
                break;
            case "UserID":
                if (context.Request.QueryString["username"] != null)
                {
                    cacheKey = context.Request.QueryString["username"];
                }
                else
                {
                    if (Request.IsAuthenticated == true)
                    {
                        cacheKey = context.User.Identity.Name;
                    }
                    else
                    {
                        cacheKey = string.Empty;
                    }
                }
                break;
        }
        return cacheKey;

    }

1. 这段代码比较长，但逻辑非常简单，我们只要直接看最后一个Case，这里用户判断的arg参数就是VarayByCustom中定义的那个值，我们现在定义的是"UserID"，所以这个判断就进入到了这个分支之中，而这个函数要执行的一个任务就是去的一个String值，ASP.Net缓存机制允许我们用这种机制取代URL参数或者控件的值来取得所需的参数，剩下的缓存机制就和前面的大同小异了，这样我们就可以以我们自己的方式取得参数值，从而灵活控制缓存的有效和过期。

      利用缓存的机制对性能的提升非常明显，然而“金无足赤，人无完人”，缓存机制也有缺点，那就是数据过期的问题。一旦应用程序数据或者页面结果值发生的改变，那么在缓存有效期范围内，你所获得的结果将是过期的、不准确的数据。那么我们是否应该为了追求高性能，而不顾所谓“数据过期”所带来的隐患呢？显然，在类似于股票系统这种数据更新频繁的特定场景下，数据过期的糟糕表现甚至比低效的性能更让人难以接受。故而，我们需要在性能与数据正确性间作出权衡。所幸的是，.Net Framework 2.0引入了一种新的缓存机制，它为我们的“鱼与熊掌兼得”带来了技术上的可行性，下一讲，我们将会涉及到这一部分的内容。