ASP.NET MVC 视图引擎比较
Posted
技术标签:
【中文标题】ASP.NET MVC 视图引擎比较【英文标题】：ASP.NET MVC View Engine Comparison 【发布时间】：2010-11-29 21:28:55 【问题描述】：我一直在 SO 和 Google 上搜索可用于 ASP.NET MVC 的各种视图引擎的细分，但除了对视图引擎是什么的简单高级描述外，没有找到更多信息。
我不一定要寻找“最佳”或“最快”，而是在各种情况下对主要参与者（例如默认的 WebFormViewEngine、MvcContrib 视图引擎等）的优势/劣势进行一些现实世界的比较。我认为这对于确定从默认引擎切换是否对给定项目或开发组有利。
有没有人遇到过这样的比较？
【问题讨论】：
【参考方案1】：ASP.NET MVC 视图引擎（社区 Wiki）
由于似乎不存在一个完整的列表，让我们从这里开始。如果人们添加他们的经验（尤其是为其中之一做出贡献的任何人），这对 ASP.NET MVC 社区可能具有很大的价值。任何实现IViewEngine（例如VirtualPathProviderViewEngine）的东西在这里都是公平的。只需按字母顺序排列新的视图引擎（将 WebFormViewEngine 和 Razor 放在顶部），并在比较时尽量保持客观。
System.Web.Mvc.WebFormViewEngine
设计目标：
一个视图引擎，用于渲染 Web 表单页面的响应。
优点：
无处不在，因为它随 ASP.NET MVC 一起提供 ASP.NET 开发人员的熟悉经验 智能感知 可以使用 CodeDom 提供程序选择任何语言（例如 C#、VB.NET、F#、Boo、Nemerle） 按需编译或precompiled查看缺点：
由于存在不再适用于 MVC 的“经典 ASP.NET”模式（例如 ViewState PostBack）而导致使用混乱 有助于“标签汤”的反模式 代码块语法和强类型可能会阻碍 IntelliSense 强制执行的样式并不总是适合内联代码块 设计简单模板时可能会产生噪音例子：
<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) %>
<ul>
<% foreach(var p in model)%>
<li><%=p.Name%></li>
<%%>
</ul>
<%else%>
<p>No products available</p>
<%%>
System.Web.Razor
设计目标：
优点：
紧凑、富有表现力和流畅 简单易学 不是一种新语言 具有出色的智能感知 可单元测试 无处不在，随 ASP.NET MVC 提供缺点：
产生与上面提到的“标签汤”略有不同的问题。服务器标签实际上提供了围绕服务器和非服务器代码的结构，Razor 混淆了 html 和服务器代码，使得纯 HTML 或 JS 开发具有挑战性（参见 Con Example #1），因为您最终不得不“转义” HTML 和/或 javascript在某些非常常见的条件下标记。 封装性+可重用性差：像调用普通方法一样调用 razor 模板是不切实际的 - 实际上，razor 可以调用代码，但反之则不行，这会鼓励代码和演示的混合。 语法非常面向 html；生成非 html 内容可能很棘手。尽管如此，razor 的数据模型本质上只是字符串连接，因此语法和嵌套错误既不会静态检测也不会动态检测，尽管 VS.NET 设计时帮助在一定程度上缓解了这种情况。可维护性和可重构性可能会因此受到影响。Con 示例 #1（注意 "string[]..." 的位置）：
@
<h3>Team Members</h3> string[] teamMembers = "Matt", "Joanne", "Robert";
foreach (var person in teamMembers)
<p>@person</p>
Bellevue
设计目标：
将 HTML 视为一流的语言，而不是将其视为“纯文本”。 不要弄乱我的 HTML！数据绑定代码（Bellevue 代码）应与 HTML 分开。 强制执行严格的模型-视图分离
Brail
设计目标：
Brail 视图引擎已被移植 从 MonoRail 到与 Microsoft ASP.NET MVC 框架。为了 Brail 简介，请参阅 Castle project website 上的文档。
优点：
仿照“手腕友好的 Python 语法” 按需编译的视图（但没有可用的预编译）缺点：
设计为使用Boo 语言编写例子：
<html>
<head>
<title>$title</title>
</head>
<body>
<p>The following items are in the list:</p>
<ul><%for element in list: output "<li>$element</li>"%></ul>
<p>I hope that you would like Brail</p>
</body>
</html>
Hasic
Hasic 使用 VB.NET 的 XML 文字，而不是像大多数其他视图引擎那样使用字符串。
优点：
有效 XML 的编译时检查 语法着色 完整的智能感知 编译视图 使用常规 CLR 类、函数等的可扩展性 无缝的可组合性和可操作性，因为它是常规的 VB.NET 代码 可单元测试缺点：
性能：在将其发送到客户端之前构建整个 DOM。例子：
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
设计目标：
NDjango 是 .NET 上的Django Template Language 平台，使用F# language。
优点：
NDjango release 0.9.1.0 seems to be more stable under stress thanWebFormViewEngine
带有语法着色、代码完成和即时诊断功能的 Django 模板编辑器（仅限 VS2010）
与 ASP.NET、Castle MonoRail 和 Bistro MVC 框架集成
NHaml
设计目标：
Rails Haml 视图引擎的.NET 端口。 来自the Haml website：
Haml 是一种使用的标记语言 简洁明了地描述 任何 Web 文档的 XHTML，没有 使用内联代码... Haml 避免了 需要将 XHTML 显式编码为 模板，因为它实际上是 XHTML 的抽象描述， 用一些代码来生成动态 内容。
优点：
简洁的结构（即 D.R.Y.） 缩进很好 结构清晰 C# Intellisense（适用于没有 ReSharper 的 VS2008）缺点：
从 XHTML 中抽象出来，而不是利用熟悉的标记 VS2010 没有智能感知例子：
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
设计目标：
一个基于视图引擎 NVelocity 这是一个 .NET 端口 流行的 Java 项目 Velocity.
优点：
易于读/写 简洁的视图代码缺点：
视图中可用的辅助方法数量有限 不会自动集成 Visual Studio（智能感知、视图的编译时检查或重构）例子：
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
设计目标：
SharpTiles 是JSTL 的部分端口 结合 Tiles framework 背后的概念（截至里程碑 1）。
优点：
熟悉 Java 开发人员 XML 样式的代码块缺点：
...例子：
<c:if test="$not fn:empty(Page.Tiles)">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark View Engine
设计目标：
这个想法是允许 html 控制流程和代码以适应 无缝衔接。
优点：
生成更具可读性的模板 C# Intellisense（适用于没有 ReSharper 的 VS2008） SparkSense plug-in 用于 VS2010（与 ReSharper 一起使用） 提供强大的Bindings feature 以摆脱视图中的所有代码，让您轻松创建自己的 HTML 标签缺点：
模板逻辑与文字标记没有明确的分离（这可以通过命名空间前缀来缓解）例子：
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">$p.Name</li>
</ul>
<else>
<p>No products available</p>
</else>
<Form style="background-color:olive;">
<Label For="username" />
<TextBox For="username" />
<ValidationMessage For="username" Message="Please type a valid username." />
</Form>
StringTemplate View Engine MVC
设计目标：
轻巧。没有创建页面类。 快。模板被写入响应输出流。 已缓存。模板被缓存，但使用 FileSystemWatcher 来检测 文件更改。 动态。模板可以在代码中动态生成。 灵活。模板可以嵌套到任何级别。 符合MVC原则。促进 UI 和业务的分离 逻辑。所有数据都是提前创建的 时间，并传递给模板。
优点：
熟悉 StringTemplate Java 开发人员缺点：
简单的模板语法会干扰预期的输出（例如jQuery conflict）Wing Beats
Wing Beats 是用于创建 XHTML 的内部 DSL。它基于 F# 并包含一个 ASP.NET MVC 视图引擎，但也可以仅用于其创建 XHTML 的能力。
优点：
有效 XML 的编译时检查 语法着色 完整的智能感知 编译视图 使用常规 CLR 类、函数等的可扩展性 无缝的可组合性和可操作性，因为它是常规 F# 代码 可单元测试缺点：
您真正编写的不是 HTML，而是在 DSL 中表示 HTML 的代码。XsltViewEngine (MvcContrib)
设计目标：
从熟悉的 XSLT 构建视图
优点：
无处不在 XML 开发人员熟悉的模板语言 基于 XML 的 久经考验 可以静态检测语法和元素嵌套错误。缺点：
函数式语言风格使流控制变得困难 （可能？）不支持 XSLT 2.0。 （XSLT 1.0 不太实用）。【讨论】：
@BrianLy：因为 F# 是可编译的和函数式的，这意味着它速度快、与运行时的其余部分（至少在 c# 4 之前）更具互操作性，并且是幂等的。我们一开始走的是 Ironpython 路线，但对结果并不满意。至于命名 - 我们愿意接受建议:) 由于 Brail 的缺点部分而投反对票。使用 Boo 作为语言当然不是骗局。 @Owen：是的。您必须从 C# 开发人员的角度来看待这一点。您不想仅仅为了使用模板引擎而学习另一种语言。 （当然，如果你已经知道 Boo，那很酷，但对于大多数 C# 开发人员来说，这是一个需要克服的额外障碍） 剃须刀在里面。应该更新它以按字母顺序排列 Razor。 Boo 是 Pro，而不是 Con。您已经“在”C# 之外，模板越简洁越好。 C# 并不是要在“模板”上下文中使用，它有点表现力，但不是“手腕友好”。另一方面，BOO 在创建时就考虑到了这一点，因此它更适合在模板环境中使用。【参考方案2】：我目前的选择是 Razor。它非常干净且易于阅读，并使视图页面非常易于维护。还有智能感知支持，非常棒。 ALos，当与网络助手一起使用时，它也非常强大。
提供一个简单的示例：
@Model namespace.model
<!Doctype html>
<html>
<head>
<title>Test Razor</title>
</head>
<body>
<ul class="mainList">
@foreach(var x in ViewData.model)
<li>@x.PropertyName</li>
</ul>
</body>
你有它。这是非常干净且易于阅读的。当然，这是一个简单的示例，但即使在复杂的页面和表单上，它仍然很容易阅读和理解。
至于缺点？到目前为止（我是新手）当使用一些表单助手时，缺少对添加 CSS 类引用的支持，这有点烦人。
谢谢 Nathj07
【讨论】：
噢！刚刚注意到这个讨论有多老了。哦，好吧，也许有人会找到它，但它仍然很有用。【参考方案3】：我知道这并不能真正回答您的问题，但不同的视图引擎有不同的用途。例如，Spark View Engine 旨在通过使所有内容流畅和易读来消除您对“标签汤”的看法。
最好的办法是只看一些实现。如果它看起来很符合您的解决方案的意图，请尝试一下。您可以在 MVC 中混合和匹配视图引擎，因此如果您决定不使用特定引擎，这应该不是问题。
【讨论】：
感谢您的回答。当我认为“有人必须已经完成摘要”时，我实际上是在开始您的建议。我希望对这些类型的设计目标和缺点进行一些汇总。 “Spark 视图引擎……旨在通过使所有内容流畅和易读来消除您对“标签汤”的看法。”这意味着构建它的原因以及默认视图引擎的缺点。列表中还有一个项目符号。【参考方案4】：检查此SharpDOM 。这是一个用于生成 html 和 asp.net mvc 视图引擎的 c# 4.0 内部 dsl。
【讨论】：
听起来是构建视图的唯一合理方法。 你能把它添加到一般维基的答案吗？ 我在 CodePlex 或 Google 上找不到它了。去哪儿了？？ （它仍在 Codeproject 上：codeproject.com/Articles/667581/…）【参考方案5】：我喜欢ndjango。它非常易于使用且非常灵活。您可以使用自定义标签和过滤器轻松扩展视图功能。我认为“与 F# 密切相关”是优势而不是劣势。
【讨论】：
【参考方案6】：我认为此列表还应包括每个视图引擎的示例，以便用户无需访问每个网站即可了解每个引擎的风格。
图片说一千个单词，标记示例就像视图引擎的屏幕截图:) 所以这是我最喜欢的Spark View Engine
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">$p.Name</li>
</ul>
<else>
<p>No products available</p>
</else>
【讨论】：
看起来太像冷融合了。我不喜欢像这样将代码混合到标记中。它变得难以维护。以上是关于ASP.NET MVC 视图引擎比较的主要内容，如果未能解决你的问题，请参考以下文章