Asp.net（8）
阅读目录：
1.开篇介绍2.System.Web.Optimization 组件3.System.Web.Optimization 组件基本原理4.扩展自定义类型静态文件
1】开篇介绍
这篇文章将简单的分析一下有关静态文件捆绑的ASP.NET组件System.Web.Optimization的运行原理及基本的缓存问题；
在我们的项目里面充斥着很多静态文件，为了追求模块化、插件化很多静态文件都被设计成模块的方式或者被分解，在需要的时候在通过组合的方式在UI层上使用；这就带来一个问题，文件多了会影响浏览器加载页面的速度，而且由于浏览器的并发限制，对于并行的请求不是无限制的，所以捆绑静态文件的功能就产生；其实在以前，IIS还没有集成管道模型的时候我们只能通过动态资源的方式进行输出，也就是我们经常在*aspx页面里看见很多*.axd结尾的请求，当然多数情况下是配合ASP.NETAJAX用来输出动态JS、HTMDOM、CSS用的；
最新的IIS已经很好的集成了ASP.NET管道模型，也就是说我们完全可以通过ASP.NET本身的扩展来控制所有经过IIS的请求，包括静态文件，所以让捆绑静态文件成为了可能；
下面我们将分析一下System.Web.Optimization组件的基本运行原理，它是如何动态加载的，如何控制缓存的；
2】System.Web.Optimization 组件
每当我们新建一个ASP.NETMVC4站点的时候都会在～/App_Start目录下有一个BundleConfig.cs的启动文件，当然创建其他的ASP.NET4.0及4.0以上的项目也会有；
我第一次看见这个文件实在让我困惑，所以我打算简单的分析一下，知道其基本原理；
代码是一个静态方法，然后传入一个BundleCollection集合对象，其实就是Bundle对象的集合，然后通过向集合内部注册多个Bundle；每个Bundle对应着多个静态文件，可以想象成就是键值对集合；通过后面的Include方法包含N多个静态文件，这里的静态文件路径可以是符合特定规则的字符串，由它内部去计算；
这是注册阶段，然后就是使用阶段，使用阶段很简单只要我们通过我们注册的Key字符串就能直接引用这些静态文件列表；
我们只要关注Styles.Render、Scripts.Render两个方法，这两个方法是想页面注入之前在后台配置的静态文件列表；这样我们在客户端看见的就是被捆绑过后的文件集合了；
文件的连接地址已经是被捆绑过后的地址了，这个地址就是我们在之前注册的时候用的key，后面它需要这个key去获取value 静态文件列表；要想你的捆绑起效果需要在注册的时候加上一段：BundleTable.EnableOptimizations =代码，意思是说开启捆绑，如果不开启捆绑则默认在调试环境里将不起效果，因为System.Web.Optimization使用了默认捆绑策略，如果是在Debug模式下，将不启用捆绑，如果你人为的设置了将覆盖默认设置；
使用就是这些，下面我们需要搞懂它是如何运行的，要了解一下它的基本原理；
3】System.Web.Optimization 组件基本原理
既然IIS集成了管道模型，那么我们肯定是能找到对应的HttpModule的，为了节省时间我就不去下载源码了，我们直接用反编译工具看一下；
这就是Bundle的HttpModule，它只用来处理 Bundle的连接地址，虽然它在HTTP的管道中；找到它就好顺藤摸瓜了，但是奇怪的是我在Web.config里没有发现它的配置信息，奇怪了，难道它还跑去系统文件改，当然是不可能的；所以我一时还想不起能有什么办法动态注册，提起动态注册突然有了思路，好像有一个Assembly级别的特性用来注册Application_Start启动时候的前置代码，会在Application启动之前执行，来看一下；
果然藏着这里呢，它注册了一个PreApplicationStartCode静态类，使用Start方法启动；
这段代码很简单，先判断有没有执行过注册，如果没有就执行动态注册，这个动态注册组件是.NETFramework自带的，在Microsoft.Web.Infrastructure里面只不过属于平台相关的，跟ASP.NET没有直接关系，我们可以用Microsoft.Web.Infrastructure来开发自己的WEB组件；这里有一个疑问，为什么静态方法也要加判断呢，不是只会执行一次吗，因为静态方法的执行是不受控制的，所以如果不加判断很有可能会注册多次，出于严谨考虑还是加上；
现在基本上我们已经找到源头了，服务端这里我们先放一下，对于客户端的疑问很多，它既然帮我们捆绑了，那么缓存是如何处理的，也就是说它的输出缓存有没有设置，如果设置了不是有问题；
【客户端缓存相关】
为了很好的了解请求之间的信息，我们用Fiddler监听一下；
我们看见它的Cache部分是用了If-Modified-Since来表示本地的文件的最后一次修改，这样是为了能够让服务器去验证文件是否改动，如果没有改动服务器的响应状态码为304，说明Bundle在输出的时候并没有设置对这个文件进行客户端强制缓存，我们通过Pragma: no-cache头也能看出来了；
那么我们得出结论，所有Bundle出来的文件都不可能直接缓存在浏览器中，每次都会带上Cache段If-Modified-Since去验证服务器的文件版本；刚好这里我们可以跟动态输出的静态文件地址的后面的参数对上了；
/Content/css?v=ZPnWVRT3c0yyrVDPmI-xkJuhBdJfQsL3A0K5C9WTOk01
这个链接后面的v参数是表示当前Bundle后虚拟文件的版本，如果我们在服务器上把文件修改了之后那么这个文件的If-Modified-Since验证就失败了，会生成新的版本号作为连接的参数；我们来看一下，心里踏实；
我加了一个width:auto的style，那么这个时候我刷新客户端应该是不会再有304出现了；
显然/Content/css?v=doYFOk3BdOYWDIRbQ7juV6eQdlJAu6RtC0G13El7X041 文件的版本变了，那么Response也不应该是304了；
如果静态文件的版本号发生改变，根本就不会带上 If-Modified-Since，这个是用在每次进行进行Post是用来验证的；其实意思就是说如果没有IIS集成模式那么捆绑文件的方式只能改变静态文件的文件名；
4】扩展自定义类型静态文件
Bundle对象是所有需要捆绑文件的基类，如果我们需要扩展一些静态文件，如一些特定领域的静态文件，我们可以直接继承这个类；
【XML文件的缓存】
扩展XML文件很简单，我们只需要继承一下Bundle对象，所有关于动态生成URL都有专门的对象处理，我们来看下代码；
public class XmlBundle : Bundle
public XmlBundle(string path) : base(path) { }
public static class XmlBundleRender
public static IHtmlString Render(string path)
BundleResolver bundle = new BundleResolver(BundleTable.Bundles);
return new HtmlString(
string.Format(@&&link href=&&{0}&&
rel=&&stylesheet&&/&&, bundle.GetBundleUrl(path)));
首先我们需要一个继承自Bundle对象的XmlBundle，用来表示我们所有将要传输的XML文件捆绑容器，然后我们需要一个静态方法用来注册捆绑后的URL；
这个URL的生成有专门的BundleResolver对象来完成，我们只需要传入所有的BundleCollection对象，我这里为了能在浏览器中测试所以写了一段stylesheet类型的link；这样我们就能直接在我们需要的地方直接使用了，我在index视图中引用：@MvcApplication4.Seed.XmlBundleRender.Render(&~/custom/xml&);是不是很简单，这样我们就能对所有想控制捆绑的文件进行捆绑，只需要继承加简单的静态方法辅助；
我们来看一下我们的XML文件是否具有所有缓存特性；
第一次请求没有加If-Modified-Since段，返回的内容是一个简单的&model&222&/model& 测试简单，现在我们看它是否在下一次不改变内容的情况下使用缓存；
在我们预料之中，使用了缓存数据，下面我们需要把服务器上的XML文件进行修改，将222改成看是否自动刷新本地缓存也就是说不会是304返回状态；
也刷新缓存，符合理论根据，正确的返回了我们修改后的值；
结：其实HTTP不仅仅用在浏览器中，会有很多使用HTTP的场合，所以我们能很好的将这种功能用来捆绑一些图片、文字等多种场合中，确实是个不错的组件；文章结束，谢谢；
作者：王清培
本文版权归作者和CSDN共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：119259次
积分：2534
积分：2534
排名：第10173名
原创：122篇
评论：81条
《.NET框架设计—模式、配置、工具》
(1)(2)(1)(1)(3)(4)(1)(2)(2)(2)(3)(4)(2)(4)(2)(2)(1)(4)(2)(1)(2)(1)(2)(3)(2)(2)(1)(1)(6)(6)(16)(16)(12)(2)(1)(2)(2)(1)自由、创新、研究、探索
Linux/Windows Mono/DotNet [ Open Source .NET Development/ 使用开源工具进行DotNet软件开发]锐意进取，志存高远.成就梦想，只争朝夕.从你开始，创新世界.【That I exist is a perpetual supprise which is life. Focus on eCommerce】
17:20 by 熬夜的虫子,&1152&阅读,&
　　作为web开发人员大家大多了解一些网站的性能优化方法，其实大部分方法都不复杂,例如针对前端js和css的压缩来减少请求大小，通过合并来减少请求次数。这里站在.Net后端程序员的角度来看一下如何最简单快捷的处理这一类需求。
　　全文分3节 combres，mvc4的Bundle，以及2者的对比和个人的意见观点。
　　Combres是一个.NET程序库，能够缩小，压缩，合并，以及缓存的JavaScript和CSS资源，ASP.NET和ASP.NET MVC的Web应用程序。简单地说，它可以帮助您的应用程序更好的页面加载速度。
　　源代码存在&/buunguyen/combres
　　通过nuget添加combres非常简单
　　加载完成后 .Net3.5的同学需要按照combres.readme的指导，首先删除掉AppStart_Combres.cs然后在global.asax中添加Combres引用，然后在RegisterRoutes()&或者&Application_Start()添加方法RouteTable.Routes.AddCombresRoute("Combres")
　　.Net4.0的同学可以忽略这一步，你们会在发现nuget包安装程序（下面简称包管理）已经自动帮你们生成了这样一段代码
public static class Combres {
public static void PreStart() {
RouteTable.Routes.AddCombresRoute("Combres");
　　下面最主要的就是就是配置combres.xml,至于webconfig的配置包管理已经帮大家设置完成。
　　为了方便测试，我们建个白板页面，然后添加最简单的js文件和css文件。
　　那么下面来看测试效果，我们先建一个简单的测试页面。
ViewBag.Title = "Home Page";
&script src="~/Scripts/Demo/JScript1.js" type="text/javascript"&&/script&
&script src="~/Scripts/Demo/JScript2.js" type="text/javascript"&&/script&
&script src="~/Scripts/Demo/JScript3.js" type="text/javascript"&&/script&
&link href="~/Content/Demo/StyleSheet1.css" rel="stylesheet" type="text/css" /&
&link href="~/Content/Demo/StyleSheet2.css" rel="stylesheet" type="text/css"
&link href="~/Content/Demo/StyleSheet3.css" rel="stylesheet" type="text/css"
　　打开fiddler查看页面请求。
　　然后我们使用combres修改页面代码
　　mvc：　
1 @using Combres.Mvc
ViewBag.Title = "Home Page";
5 @bresLink("siteCss")
6 @bresLink("siteJs")
　　webform：
1 &%= bresLink("siteJs") %&
2 &%= bresLink("siteCss") %&
　　再来查看页面请求
　　请求次数变为了2次，大小也被压缩的非常低。
　　Combres的实现原理不复杂，服务器端先加载配置缓存起来，根据配置节点生成hash值，具体实现如下　
public string Generate(ResourceSet rs)
if (Log.IsDebugEnabled)
Log.Debug("Computing hash for set " + rs.Name + ".
Current hash: " + rs.Hash);
var contributingFactors = new List&object& {rs.DebugEnabled};
rs.Filters.ToList().ForEach(contributingFactors.Add);
rs.CacheVaryProviders.ToList().ForEach(contributingFactors.Add);
rs.Resources.ToList().ForEach(r =&
contributingFactors.Add(r.ReadFromCache(true));
contributingFactors.Add(r.ForwardCookie);
contributingFactors.Add(r.Mode);
contributingFactors.Add(r.Minifier);
var hash = contributingFactors.Select(f =& f.GetHashCode())
.Aggregate(17, (accum, element) =& 31 * accum + element)
.ToString();
if (Log.IsDebugEnabled)
Log.Debug("New hash: " + hash);
　　得出来的值就是我们上面看到的combres.xsd/setname/hashvalue中的hashvalue，当我们请求产生的时候会由一个CombresHandler根据hashvalue来获取对应的资源并且进行合并压缩。
　　处理流程首先判断你的浏览器是否支持压缩,通过Context.Request.Headers["Accept-Encoding"]。
　　如果判断为接受combres会对资源进行2层压缩，我们这里简单称只为minifier和gzip。
　　如果浏览器不支持压缩那么gzip这一层会被忽略，minifier的压缩方法使用YuiJSMinifier和YuiCssMinifier，方法依赖雅虎的开源组件pressor
　　handler会为新的请求生成一个cachekey：&Combres/Combres.RequestProcessor/siteJs//gzip&
　　和etag key&Combres/Combres.RequestProcessor/siteJs//gzip/@etag&（实际上真正存于Context.Response.Cache的ETag是""）
　　分别对应服务器端缓存和浏览器缓存，当下次请求已经发现有key存在，便从缓存中直接获取资源或者直接304。
　　根据结果图来看，combres确实是一款很不错的工具。
&MVC4的Bundle
　　MVC4以后自带了Bundling和Minification。操作也很简单，新建一个mvc4项目。在App_Start文件夹下找到BundleConfig.cs。
　　添加如下代码：
public static void RegisterBundles(BundleCollection bundles)
bundles.Add(new ScriptBundle("~/bundles/jquerydemo").Include(
"~/Scripts/Demo/JScript1.js",
"~/Scripts/Demo/JScript2.js",
"~/Scripts/Demo/JScript3.js"));
bundles.Add(new StyleBundle("~/Content/cssdemo").Include(
"~/Content/Demo/StyleSheet1.css",
"~/Content/Demo/StyleSheet2.css",
"~/Content/Demo/StyleSheet3.css"));
　　页面端添加：
1 @Styles.Render("~/Content/cssdemo")
2 @Scripts.Render("~/bundles/jquerydemo")
　　然后记住在BundleConfig.cs添加BundleTable.EnableOptimizations =不然MVC4不会启用压缩，减少请求数量和带宽。
　　我们来看一下效果图：
　　请求次数减少，也有压缩。但是比起combres效率要差了一些。但是这样未必就是说combres要更好。
　　2者相比较而已combres的效率要高一些，但是mvc4作为原生自带的功能，对于版本管理比较苛刻的系统还是具有优势，并且对于大型项目还要涉及到cdn问题。
　　目前combres是不支持cdn的，虽然作者给出了相关的话题，但是作者本人最后还有给出了不是令人满意的答复。
　　相对MVC4的Bundle是支持cdn的，只需要在对应节点添加&bundles.UseCdn = true即可。
　　所以根据各自项目不同的场景，酌情处理吧。
　　个人推荐静态资源的压缩和合并尽量在前端就做掉，例如grunt。这样不管是cdn还是部署发布都更合理没有必要再浪费后端的处理资源。
本篇先到此，希望对大家有帮助！
原创作品允许转载,转载时请务必以超链接形式标明文章原始出处以及作者信息。作者：熬夜的虫子点击查看:
阅读(...) 评论()
随笔 - 14820
评论 - 10103390人阅读
asp.net（5）
转载于：/linfei721/archive//3056497.html
MVC中有个专门提供JS和CSS压缩的类，BundleCollection，其实这个类也可以在asp.net中用，
关于BundleCollection类的详细推荐个地址：
我这里只是记录下使用过程中遇到的两个小问题
1.css被压缩后，里面图片路径文件的问题
我们可以看到MVC中&BundleConfig这个类里，都是自动生成的好多需要压缩的JS和CSS
bundles.Add(new StyleBundle(&~/Content/Css&).Include(&~/Content/layout.css&, &~/Content/wysiwyg.css&));
view在头部这样写就可以导入 &~/Content/layout.css 和~/Content/wysiwyg.css的CSS了
@Styles.Render(&~/Content/Css&)
照上面方法，我继续在后面加了个CSS，就是站点的皮肤，注意蓝色位置，已经不在Content文件下级了
bundles.Add(new StyleBundle(&~/Content/Css&).Include(&~/Content/layout.css&,&~/Content/wysiwyg.css&, &~/Content/themes/blue/styles.css&));
这样在开发的时候没什么问题，因为在开发模式下CSS和JS是没有被压缩的，但是我把网站发布后就出问题了，
Content/themes/blue/styles.css 里图片都是这样写的&background: url(img/bg_navigation.png)，有人会说，为什么不写 /Content/themes/blue/img/bg_navigation.png,如果在MVC用到了区域，这样写路径也会就会出问题
如何在不发布网站的情况下测试压缩CSS呢？在BundleConfig 类里加上
BundleTable.EnableOptimizations = true;
或修改Web.config
&compilation debug=&false& targetFramework=&4.0&&
看看压缩前后的CSS路径终于发现问题了
原来，我们写的&new StyleBundle(&~/Content/Css&) 会影响到压缩后的路径
解决办法：
对于皮肤的CSS，我们重写一个声明
bundles.Add(new StyleBundle(&~/Content/themes/blue/Css&).Include(&~/Content/themes/blue/styles.css&));
这样图片就能找到了
2.压缩javascript文件的是时候，如果文件名带有 .min居然不压缩，连文件都不导入，例如
bundles.Add(new ScriptBundle(&~/bundles/easyui&).Include(&~/Scripts/my/jquery.easyui.min.js&));
这样的文件在压缩后不会被导入，解决办法
改JS名字，去掉min 或 在view里写&@Scripts.Render(&~/Scripts/my/jquery.easyui.min.js&)，这样就不会被压缩了
其实带min已经是被压缩了的，如果对这个文件进行压缩，运行里面相关方法会报错
写的有点乱，只是记录下
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：901352次
积分：8136
积分：8136
排名：第1630名
原创：116篇
转载：176篇
评论：96条
(4)(2)(1)(2)(1)(2)(1)(1)(3)(2)(2)(1)(3)(1)(5)(2)(8)(3)(1)(1)(4)(5)(4)(6)(8)(3)(11)(2)(3)(1)(2)(2)(4)(4)(2)(2)(2)(3)(1)(7)(7)(4)(1)(1)(4)(1)(1)(3)(4)(3)(2)(5)(3)(1)(6)(2)(2)(3)(1)(2)(8)(1)(6)(5)(4)(4)(10)(25)(9)(11)(5)(6)(2)(7)(7)(13).NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)
1】开篇介绍
这篇文章将简单的分析一下有关静态文件捆绑的ASP.NET组件System.Web.Optimization的运行原理及基本的缓存问题；
在我们的项目里面充斥着很多静态文件，为了追求模块化、插件化很多静态文件都被设计成模块的方式或者被分解，在需要的时候在通过组合的方式在UI层上使用；这就带来一个问题，文件多了会影响浏览器加载页面的速度，而且由于浏览器的并发限制，对于并行的请求不是无限制的，所以捆绑静态文件的功能就产生；其实在以前，IIS还没有集成管道模型的时候我们只能通过动态资源的方式进行输出，也就是我们经常在*aspx页面里看见很多*.axd结尾的请求，当然多数情况下是配合ASP.NETAJAX用来输出动态JS、HTMDOM、CSS用的；
最新的IIS已经很好的集成了ASP.NET管道模型，也就是说我们完全可以通过ASP.NET本身的扩展来控制所有经过IIS的请求，包括静态文件，所以让捆绑静态文件成为了可能；
下面我们将分析一下System.Web.Optimization组件的基本运行原理，它是如何动态加载的，如何控制缓存的；
2】System.Web.Optimization 组件
每当我们新建一个ASP.NETMVC4站点的时候都会在～/App_Start目录下有一个BundleConfig.cs的启动文件，当然创建其他的ASP.NET4.0及4.0以上的项目也会有；
我第一次看见这个文件实在让我困惑，所以我打算简单的分析一下，知道其基本原理；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/49fd55ac.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
代码是一个静态方法，然后传入一个BundleCollection集合对象，其实就是Bundle对象的集合，然后通过向集合内部注册多个Bundle；每个Bundle对应着多个静态文件，可以想象成就是键值对集合；通过后面的Include方法包含N多个静态文件，这里的静态文件路径可以是符合特定规则的字符串，由它内部去计算；
这是注册阶段，然后就是使用阶段，使用阶段很简单只要我们通过我们注册的Key字符串就能直接引用这些静态文件列表；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/ee8d8ca05d0219cae648.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
我们只要关注Styles.Render、Scripts.Render两个方法，这两个方法是想页面注入之前在后台配置的静态文件列表；这样我们在客户端看见的就是被捆绑过后的文件集合了；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/929daff6f4c8c9b604a.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
文件的连接地址已经是被捆绑过后的地址了，这个地址就是我们在之前注册的时候用的key，后面它需要这个key去获取value
静态文件列表；要想你的捆绑起效果需要在注册的时候加上一段：BundleTable.EnableOptimizations =
代码，意思是说开启捆绑，如果不开启捆绑则默认在调试环境里将不起效果，因为System.Web.Optimization使用了默认捆绑策略，如果是在Debug模式下，将不启用捆绑，如果你人为的设置了将覆盖默认设置；
使用就是这些，下面我们需要搞懂它是如何运行的，要了解一下它的基本原理；
3】System.Web.Optimization 组件基本原理
既然IIS集成了管道模型，那么我们肯定是能找到对应的HttpModule的，为了节省时间我就不去下载源码了，我们直接用反编译工具看一下；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/b3ff8cc5f374b2b9cba4cfc.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
这就是Bundle的HttpModule，它只用来处理&
Bundle的连接地址，虽然它在HTTP的管道中；找到它就好顺藤摸瓜了，但是奇怪的是我在Web.config里没有发现它的配置信息，奇怪了，难道它还跑去系统文件改，当然是不可能的；所以我一时还想不起能有什么办法动态注册，提起动态注册突然有了思路，好像有一个Assembly级别的特性用来注册Application_Start启动时候的前置代码，会在Application启动之前执行，来看一下；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/a8ccdadf84cdff3cdf.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
果然藏着这里呢，它注册了一个PreApplicationStartCode静态类，使用Start方法启动；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/ce90d972fd2a254d033.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
这段代码很简单，先判断有没有执行过注册，如果没有就执行动态注册，这个动态注册组件是.NETFramework自带的，在Microsoft.Web.Infrastructure里面只不过属于平台相关的，跟ASP.NET没有直接关系，我们可以用Microsoft.Web.Infrastructure来开发自己的WEB组件；这里有一个疑问，为什么静态方法也要加判断呢，不是只会执行一次吗，因为静态方法的执行是不受控制的，所以如果不加判断很有可能会注册多次，出于严谨考虑还是加上；
现在基本上我们已经找到源头了，服务端这里我们先放一下，对于客户端的疑问很多，它既然帮我们捆绑了，那么缓存是如何处理的，也就是说它的输出缓存有没有设置，如果设置了不是有问题；
【客户端缓存相关】
为了很好的了解请求之间的信息，我们用Fiddler监听一下；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/70c45a7d645bfb85ad4f34b460775.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
我们看见它的Cache部分是用了If-Modified-Since来表示本地的文件的最后一次修改，这样是为了能够让服务器去验证文件是否改动，如果没有改动服务器的响应状态码为304，说明Bundle在输出的时候并没有设置对这个文件进行客户端强制缓存，我们通过Pragma:
no-cache头也能看出来了；
那么我们得出结论，所有Bundle出来的文件都不可能直接缓存在浏览器中，每次都会带上Cache段If-Modified-Since去验证服务器的文件版本；刚好这里我们可以跟动态输出的静态文件地址的后面的参数对上了；
/Content/css?v=ZPnWVRT3c0yyrVDPmI-xkJuhBdJfQsL3A0K5C9WTOk01
这个链接后面的v参数是表示当前Bundle后虚拟文件的版本，如果我们在服务器上把文件修改了之后那么这个文件的If-Modified-Since验证就失败了，会生成新的版本号作为连接的参数；我们来看一下，心里踏实；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/c4acfde62d922c9f5c.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
我加了一个width:auto的style，那么这个时候我刷新客户端应该是不会再有304出现了；
显然/Content/css?v=doYFOk3BdOYWDIRbQ7juV6eQdlJAu6RtC0G13El7X041
文件的版本变了，那么Response也不应该是304了；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/b3bffb0a7480fac6967.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/fb0deacd17dd5e687adf0.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
如果静态文件的版本号发生改变，根本就不会带上
If-Modified-Since，这个是用在每次进行进行Post是用来验证的；其实意思就是说如果没有IIS集成模式那么捆绑文件的方式只能改变静态文件的文件名；
4】扩展自定义类型静态文件
Bundle对象是所有需要捆绑文件的基类，如果我们需要扩展一些静态文件，如一些特定领域的静态文件，我们可以直接继承这个类；
【XML文件的缓存】
扩展XML文件很简单，我们只需要继承一下Bundle对象，所有关于动态生成URL都有专门的对象处理，我们来看下代码；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/OutliningIndicators/ContractedBlock.gif" ALT="" STYLE="vertical-align: padding-right: 5 max-width: 900" NAME="code_img_closed_ac1db3cb-0ccb-4d24-b376-c3dff5d8b177"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />&View
首先我们需要一个继承自Bundle对象的XmlBundle，用来表示我们所有将要传输的XML文件捆绑容器，然后我们需要一个静态方法用来注册捆绑后的URL；
这个URL的生成有专门的BundleResolver对象来完成，我们只需要传入所有的BundleCollection对象，我这里为了能在浏览器中测试所以写了一段stylesheet类型的link；这样我们就能直接在我们需要的地方直接使用了，我在index视图中引用：@MvcApplication4.Seed.XmlBundleRender.Render("~/custom/xml");是不是很简单，这样我们就能对所有想控制捆绑的文件进行捆绑，只需要继承加简单的静态方法辅助；
我们来看一下我们的XML文件是否具有所有缓存特性；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/cf62a078908bfd3e6b49.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
第一次请求没有加If-Modified-Since段，返回的内容是一个简单的222
测试简单，现在我们看它是否在下一次不改变内容的情况下使用缓存；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/cc047aedadb438da06a70df9af742a1.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
在我们预料之中，使用了缓存数据，下面我们需要把服务器上的XML文件进行修改，将222改成看是否自动刷新本地缓存也就是说不会是304返回状态；
<img src="/blog7style/images/common/sg_trans.gif" real_src ="/blog/309/-ec11ff3f4d2f4ed2bf4b09.jpg" ALT="" STYLE="border: 1 max-width: 900"
TITLE=".NET/ASP.NET&4.5&Bundle组件（捆绑、缩小静态文件）(转载)" />
也刷新缓存，符合理论根据，正确的返回了我们修改后的值；
结：其实HTTP不仅仅用在浏览器中，会有很多使用HTTP的场合，所以我们能很好的将这种功能用来捆绑一些图片、文字等多种场合中，确实是个不错的组件；文章结束，谢谢；
原文地址：/wangiqngpei557/p/3309812.html
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。