谈谈ASP.NET Core中的ResponseCaching

注：如果NoStore没有设置成true，则Duration必须要赋值！

关于responsecacheAttribute，还有一个不得不提的属性：CacheProfilename！

它相当于指定了一个“配置文件”，并在这个“配置文件”中设置了responsecache的一些值。

这个时候，只需要在responsecacheAttribute上面指定这个“配置文件”的名字就可以了，而不用在给Duration等属性赋值了。

在添加MVC这个中间件的时候就需要把这些“配置文件”准备好！

下面的示例代码添加了两份“配置文件”，其中一份名为default，默认是缓存10分钟，还有一份名为Hourly，默认是缓存一个小时，还有一些其他可选配置也用注释的方式列了出来。

services.AddMvc(options =>{    options.CacheProfiles.Add("default",new Microsoft.AspNetCore.Mvc.CacheProfile    {        Duration = 600,// 10 min    });
options.CachePro<a href="https://m.jb51.cc/tag/file/" target="_blank" >file</a>s.Add("Hourly",new Microsoft.AspNetCore.Mvc.CachePro<a href="https://m.jb51.cc/tag/file/" target="_blank" >file</a>{    Duration = 60 * 60,// 1 hour    //Location = Microsoft.AspNetCore.Mvc.<a href="https://www.jb51.cc/tag/responsecache/" target="_blank" >responsecache</a>Location.Any,//NoStore = true,//<a href="https://www.jb51.cc/tag/vary/" target="_blank" >vary</a>By<a href="https://m.jb51.cc/tag/header/" target="_blank" >header</a> = "User-Agent",//<a href="https://www.jb51.cc/tag/vary/" target="_blank" >vary</a>By<a href="https://m.jb51.cc/tag/query/" target="_blank" >query</a>Keys = new string[] { "aaa" }});
});

现在“配置文件”已经有了，下面就是使用这些配置了！只需要在Attribute上面指定CacheProfilename的名字就可以了。

示例代码如下：

[responsecache(CacheProfilename = "default")]public IActionResult Index(){    return VIEw();}

responsecacheAttribute中还有一个varyByqueryKeys的属性，这个属性可以根据不同的查询参数进行缓存！

但是这个属性的使用需要结合下一小节的内容，所以这里就不展开了。

注：responsecacheAttribute即可以加在类上面，也可以加在方法上面，如果类和方法都加了，会优先采用方法上面的配置。

先简单解释一下这里的服务端缓存是什么，对比前面的客户端缓存，它是将东西存放在客户端，要用的时候就直接从客户端去取！

同理，服务端缓存就是将东西存放在服务端，要用的时候就从服务端去取。

需要注意的是，如果服务端的缓存命中了，那么它是直接返回结果的，也是不会去访问Action里面的内容！有点类似代理的感觉。

这个相比客户端缓存有一个好处，在一定时间内，“刷新”页面的时候会从这里的缓存返回结果，而不用再次访问Action去拿结果。

要想启用服务端缓存，需要在管道中去注册这个服务，核心代码就是下面的两句。

public voID ConfigureServices(IServiceCollection services){    services.AddResponseCaching();}
public voID Configure(IApplicationBuilder app,IHostingEnvironment env)
{
app.UseResponseCaching();
}

当然，仅有这两句代码，并不能完成这里提到的服务端缓存。还需要前面客户端缓存的设置，两者结合起来才能起作用。

可以看看下面的效果，

简单解释一下这张图，

第三次请求响应头部的部分信息如下：

Age: 16Cache-Control: public,max-age=600

这个Age是在变化的！它就等价于缓存的寿命。

如果启用了日志，也会看到一些比较重要的日记信息。

在上一小节中，我们还有提到responsecacheAttribute中的varyByqueryKeys这个属性，它需要结合ResponseCaching中间件一起用的，这点在注释中也是可以看到的！

//// Summary://     Gets or sets the query keys to vary by.//// Remarks://     Microsoft.AspNetCore.Mvc.responsecacheAttribute.varyByqueryKeys requires the//     response cache mIDdleware.public string[] varyByqueryKeys { get; set; }

举个例子(不一定很合适)来看看，假设现在有一个电影列表页面()，可以通过在URL地址上面加查询参数来决定显示第几页的数据。

如果代码是这样写的，

[ResponseCache(Duration = 600)]public IActionResult List(int page = 0){    return Content(page.ToString());}

结果就会像下面这样，三次请求，返回的都是页码为0的结果！page参数，压根就没起作用！

GET http://localhost:5001/Home/List HTTP/1.1Host: localhost:5001
HTTP/1.1 200 OK
Date: Thu,05 Apr 2018 07:38:51 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 1
Cache-Control: public,max-age=600
0
GET http://localhost:5001/Home/List?page=2 HTTP/1.1
Host: localhost:5001
HTTP/1.1 200 OK
Date: Thu,max-age=600
Age: 5
0
GET http://localhost:5001/Home/List?page=5 HTTP/1.1
Host: localhost:5001
HTTP/1.1 200 OK
Date: Thu,max-age=600
Age: 8
0

正确的做法应该是要指定VaryByQueryKeys，如下所示：

[ResponseCache(Duration = 600,VaryByQueryKeys = new string[] { "page" })]public IActionResult List(int page = 0){    return Content(page.ToString());}

这个时候的结果就是和预期的一样了，不同参数都有对应的结果并且这些数据都缓存了起来。

GET http://localhost:5001/Home/List HTTP/1.1Host: localhost:5001
HTTP/1.1 200 OK
Date: Thu,05 Apr 2018 07:45:13 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 1
Cache-Control: public,05 Apr 2018 07:45:22 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 1
Cache-Control: public,max-age=600
2
GET http://localhost:5001/Home/List?page=5 HTTP/1.1
Host: localhost:5001
HTTP/1.1 200 OK
Date: Thu,05 Apr 2018 07:45:27 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 1
Cache-Control: public,max-age=600
5

ResponseCachingMiddleware在这里是用了MemoryCache来读写缓存数据的。如果应用重启了，缓存的数据就会失效，要重新来过。

对于一些常年不变或比较少变的js,css等静态文件，也可以把它们缓存起来，避免让它们总是发起请求到服务器，而且这些静态文件可以缓存更长的时间！

如果已经使用了CDN，这一小节的内容就可以暂且忽略掉了。。。

对于静态文件，.NET Core有一个单独的StaticFiles中间件，如果想要对它做一些处理，同样需要在管道中进行注册。

UseStaticFiles有几个重载方法，这里用的是带StaticFileOptions参数的那个方法。

因为StaticFileOptions里面有一个OnPrepareResponse可以让我们修改响应头，以达到HTTP缓存的效果。

//// Summary://     Called after the status code and headers have been set,but before the body has//     been written. This can be used to add or change the response headers.public Action OnPrepareResponse { get; set; }

下面来看个简单的例子：

app.UseStaticFiles(new StaticFileOptions{    OnPrepareResponse = context =>    {        context.Context.Response.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue        {             Public = true,//for 1 year            MaxAge = System.TimeSpan.FromDays(365)        };    }});

此时的效果如下：

其一，ResponseCaching中间件对下面的情况是不会进行缓存 *** 作的！

其二，当我们使用了Antiforgery的时候也要特别的注意！！它会直接把响应头部的Cache-Control和Pragma重置成no-cache。换句话说，这两者是水火不容的！

详情可见

/// 
/// Sets the 'Cache-Control' header to 'no-cache,no-store' and 'Pragma' header to 'no-cache' overrIDing any user set value./// 
/// protected virtual voID SetDoNotCacheheaders(httpContext httpContext){    // Since antifogery token generation is not very obvIoUs to the end users (ex: MVC's form tag generates them    // by default),log a warning to let users kNow of the change in behavior to any cache headers they might    // have set explicitly.    LogCacheheaderOverrIDeWarning(httpContext.Response);
<a href="https://m.jb51.cc/tag/http/" target="_blank" >http</a>Context.Response.<a href="https://m.jb51.cc/tag/header/" target="_blank" >header</a>s[<a href="https://m.jb51.cc/tag/header/" target="_blank" >header</a><a href="https://m.jb51.cc/tag/name/" target="_blank" >name</a>s.CacheContr<a href="https://m.jb51.cc/tag/ol/" target="_blank" >ol</a>] = "no-cache,no-store";<a href="https://m.jb51.cc/tag/http/" target="_blank" >http</a>Context.Response.<a href="https://m.jb51.cc/tag/header/" target="_blank" >header</a>s[<a href="https://m.jb51.cc/tag/header/" target="_blank" >header</a><a href="https://m.jb51.cc/tag/name/" target="_blank" >name</a>s.Pragma] = "no-cache";
}

当然，在某个页面用到了Antiforgery的时候，也该避免在这个页面使用http缓存！

它会在form表单中生成一个隐藏域，并且隐藏域的值是一个生成的token ，难道还想连这个一起缓存？

在.NET Core中用ResponseCaching还是比较简单的，虽然还有一些值得注意的地方，但是并不影响我们的正常使用。

当然，最重要的还是合理使用！仅在需要的地方使用！

最后附上文中Demo的地址

href="https://github.com/catcherwong/Demos/tree/master/src/ResponseCachingDemo">ResponseCachingDemo

以上是内存溢出为你收集整理的谈谈ASP.NET Core中的ResponseCaching全部内容，希望文章能够帮你解决谈谈ASP.NET Core中的ResponseCaching所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。