适合ASP.NET MVC的视图片断缓存方式（下）：页面输出原则

那么，在缓存命中的时候，我们的Cache方法把缓存中的内容写到什么地方去了呢？

public　static　void　Cache(
　　this　HtmlHelper　htmlHelper,　
　　...)
{
　　var　content　=　...

　　if　(content　==　null)
　　{
　　　 　...
　　}
　　else　
　　{
　　　　htmlHelper.Output.Write(content);
　　}
}　

Output是什么？如果您观察ASP.NET MVC的源代码，您会发现HtmlHelper并没有这个属性。这是我在 MvcPatch中暴露出来的一个TextWriter，它便是当前正用于页面输出的HtmlTextWriter对象。因此，我这 里提出一个原则：如果您是在向页面输出内容，请务必将所有内容通过页面的Writer输出。

在原来的ASP.NET MVC实现中，由于无法从HtmlHelper中获得页面的Writer，因此如果需要输出内容， 则只能通过Response.Write方法，或由 Response.Output输出内容了。根据上图可知，如果我们直接从 Response.Output输出，那么这部分内容是无法被 RecordWriter捕获的。这意味着什么呢？这意味着，如 果我们上面不是通过HtmlHelper.Output，而是直接向 Response.Output输出，在Html.Cache嵌套的情况 下，内层缓存块的输出无法被外层缓存块捕获到。因此，如果内层缓存命中，而外层重新生成内容，则会 发现内层缓存块的内容被没有被外层记录下来。

我们可以想的再远一些。我们这种TextWriter的嵌套其实是一种什么模式呢？应该算是装饰器模式吧 。装饰器模式要求我们所有的输出都从链条的顶部输入，这样所有的“装饰”作用才会生效。如果我们获 取了其中的某一个环节，直接从这个环节输入参数，那么自然是失败的。这意味着……假如又有另外一个 组件在“行使”它的扩展权力呢？如果又有另一个组件，它在我们的RecordWriter外层又进行了包装呢？ 我们的片断缓存解决方案是一种扩展，作为扩展方案，不应该破坏其他组件正常扩展的能力。因此，我们 需要从页面的Writer中输出内容。

一个很好的反例就是ASP.NET MVC框架，您看RenderPartial方法的输出目标是什么：Response.Output 。还有FormExtensions及MvcForm 对象的输出目标是什么：还是Respo