我刚刚读过 这篇关于 ASP.NET MVC 3 中的 Razor 模板 的博文。
简单来说，我就是不明白！
也就是说，我不明白为什么我们需要这段（相当）复杂的代码来实现在我看来使用 @RenderPartial 可以更轻松（更整洁）完成的任务吗？
这是我不喜欢的：
- 模板存储为
Func 委托？
- 该模板委托保留在控制器 ViewData 中（例如 HttpContext.Current.Items）
我从该博客中读到的唯一“好处”是模板不需要单独的文件，这意味着您不需要重新编译等但
我不认为这是一个有效的论点。只要解决方案组织不受影响，额外的文件就可以。
我更喜欢使用 @RenderPartial，因为我可以将标记与主视图分开，并且可以内联（渲染时间）和 jQuery（例如 AJAX 事件）渲染它。
也许我在这里遗漏了一些东西，但是任何人都可以给出一些为什么我们应该选择 Razor 模板而不是 RenderPartial 来创建可重用内容的原因吗？
I just read this blog post on Razor Templating in ASP.NET MVC 3.
Put simply, i just dont get it!
That is, i don't see why we need this (fairly) complicated code to achieve what can be done IMO easier (and neater) with @RenderPartial ?
Here's what i don't like:
- The template is stored as a
Func<T,HelperResult> delegate?
- That template delegate is persisted in the Controller ViewData (e.g HttpContext.Current.Items)
The only "benefit" i read from that blog is that a seperate file isn't required for templating, meaning you don't need to re-compile etc.
But i don't see that as a valid argument. Extra files are fine as long as the solution organization isn't compromised.
I prefer using @RenderPartial, as i can keep my markup seperate from the master view, and i can render this both inline (render time) and with jQuery (e.g AJAX event).
Maybe i'm missing something here, but can anyone give some reasons why we should choose Razor Templating over RenderPartial to create re-usable content?
发布评论
评论（2）
好吧，您应该询问该文章的作者提出此技术的动机。
它确实说明了 Razor 的可能性。是否应该使用它是另一回事。我个人认为有一些不太复杂的替代技术（我同意您关于在请求上下文中存储
Func的观点）。@RenderPartial。@helper语法（作为本地帮助程序或全局帮助程序）TagBuilder来组装输出）既然我查看了上面的列表，我认为 MVC 可能提供了太多选择:)
更新 为了更好地说明内联模板如何有用，我写了一篇博客文章关于使用它们使用默认代码调用部分： 具有默认内容的可选 Razor 部分。
你可以用它来写这样的东西：
Well, you should ask the author of that post about his motivation for presenting this technique.
It certainly illustrates what is possible in Razor. Whether you should use it is a different matter. I personally think that there are alternative techniques that are less complicated (I agree with your points about storing a
Funcinside of the request context).@RenderPartialwhich you already mentioned.@helpersyntax (either as a local helper or a global helper)TagBuilderto assemble the output)Now that I look at the above list I think MVC might provide too much choice :)
Update To better illustrate how inline templates can be useful I wrote a blog post about using them to call sections with default code: Optional Razor Sections with Default Content.
You can use it to write something like this:
关于 Razor 的一个常见误解是它不能在 ASP.Net MVC 框架的上下文之外使用。这是最常见的情况，但剃须刀引擎的功能远不止于此。
您可以在控制台应用程序甚至库中定义剃刀模板。作为一个过于简化的示例，请考虑一个向客户端发送自动 HTML 电子邮件的应用程序。在过去，您要么诉诸字符串连接、XSLT 转换或其他方法。无论哪种方式，您都无法直观地看到您的标记，并且操作成为维护的噩梦。
使用 Razor 模板，您可以将模板定义为 HTML 标记，您可以轻松地对其进行可视化和测试。
这是一篇展示此功能的优秀文章：http://www.west-wind.com/weblog/posts/2010/Dec/27/Hosting-the-Razor-Engine-for-Templated-in-NonWeb-Applications< /a>
注意： 我并不是说您指向的链接显示了这一点，只是举例说明为什么您希望超越 @marcind 的答案中列出的方法。
A common misconception about Razor is that it can't be used outside the context of the ASP.Net MVC framework. It is the most common scenario, however the power of razor engine goes beyond that.
You can define razor templates in a console app or even a library. As a over simplified example, consider an app that sends automated HTML emails to clients. In old days, you would either resort to string concatenation or XSLT transform or something else. Either way, you cannot visually see your markup and manipulation becomes a maintenance nightmare.
With Razor templates, you can define your template as HTML markup where you can easily visualize and test it.
Here's an excellent article that demonstrates this capability: http://www.west-wind.com/weblog/posts/2010/Dec/27/Hosting-the-Razor-Engine-for-Templating-in-NonWeb-Applications
Note: I'm not saying that the link you pointed is showing this, just an example of why you would want to go beyond the methods listed in @marcind's answer.