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

作者佚名技术来源 NET编程浏览发布时间 2012-05-20

nse.Output。这意味着，ASP.NET MVC框架的做法直接破坏了视图的扩展能力。也直接放倒了我们的片断缓存实现。因此，我最终构建了 MvcPatch项目，因为在这一点上（以及其他一些方面，之前也有所提及）使用扩展的方式实在是无法进行修补的。

所以国外社区有种调侃称，微软产品是好的，但是他们自己不知道该如何用好自己的产品。例如我一直说的WebForms的滥用，还有这里ASP.NET MVC实现。前者更像是一种商业策略，而后者可能……就令人摸不着头脑了。

我没有说“微软的确不知道如何用好自己的产品”。因为从ASP.NET MVC的代码中可以发现，好像他们并非不知道我刚提出的页面输出原则。证据在于，他们已经在ViewPage中留有一个“入口”了：

public　class　ViewPage　:　Page,　IViewDataContainer 　　... 　　public 　HtmlTextWriter　Writer 　　{ 　　　　get; 　　　　private　set; 　　} 　　protected　override　void　Render(HtmlTextWriter　writer) 　　{ 　　　　Writer　= 　writer; 　　　　try 　　　　{ 　　　　　　base.Render(writer); 　　　　} 　　　　finally 　　　　{ 　　　　　　Writer　=　null; 　　　　} 　　} }

看看这段代码在做什么？这段代码重写了Render方法，将外部传入的HtmlTextWriter对象保留了起来！这意味着 ViewPage.Writer属性获得的便是当前正在输出的HtmlTextWriter对象！也就是说，ASP.NET MVC似乎在建议您说，如果您非要在页面上使用Response.Output输出的话，现在就改成Writer的输出吧：

<%　Response.Write("Hello　World");　%> <%　Writer.Write("Hello　 World");　%>

不知道是可惜还是可笑，如果您在代码中对Writer属性使用Find All References，您会发现除了在 ViewMasterPage或ViewUserControl中继续暴露Writer属性之外，就再也没有使用过了……那么 RenderPartial在做什么？FormExtensions在做什么？谁知道……我同样不知道的是，如果微软自己没有这个“意识”，那么又为什么要主动保留Render时的Writer呢？

不管这些了。我们最后总结一下：

如果您在使用WebForm模型，请像ViewPage那样保留当前Writer，并且向Writer内输出，不要搞 Response.Write/Output。

如果您在编写视图的辅助方法，请向HtmlHelper.Output输出，而不是Reponse.Write/Output。

如果您发现其他项目在使用Response.Write/Output，请将它修改成页面的Writer输出。

……

嗯？您说HtmlHelper没有Output属性？没关系，下载代码以后自己修改编译一下，或直接使用 MvcPatch吧。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!

上一页 1 2

分享到：更多

你可能对下面的文章感兴趣

上一篇: ASP.NET自定义控件组件开发第三章为控件添加事件前篇下一篇: ASP.NET页面生成详解

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

随机推荐