ASP.NET MVC视图引擎（社区Wiki）
由于似乎不存在完整的列表，因此让我们从SO开始。如果人们增加了他们的经验（尤其是其中之一的贡献者），那么这对于ASP.NET MVC社区可能具有巨大的价值。任何实现IViewEngine（例如VirtualPathProviderViewEngine）的行为在这里都是公平的游戏。只需按字母顺序排列新的视图引擎（将WebFormViewEngine和Razor放在顶部），然后尝试比较客观即可。
System.Web.Mvc.WebFormViewEngine
设计目标：
用于向响应呈现Web窗体页面的视图引擎。
优点：
- 随处可见，因为它随ASP.NET MVC一起提供
- ASP.NET开发人员的熟悉经验
- 智能感知
- 可以使用CodeDom提供程序选择任何语言（例如C＃，VB.NET，F＃，Boo，Nemerle）
- 按需编译或预编译视图
缺点：
- 使用被存在于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。标签在某些非常常见的条件下。
- 封装+可重用性差：将剃刀模板当作普通方法来调用是不切实际的-在实践中，剃刀可以调用代码，反之亦然，这会鼓励代码和表示的混合。
- 语法非常面向html；生成非HTML内容可能很棘手。尽管如此，razor的数据模型本质上只是字符串连接，因此虽然VS.NET设计时的帮助在某种程度上减轻了这种麻烦，但是语法和嵌套错误既不会静态也不会动态检测。因此，可维护性和可重构性会受到影响。
没有记录的API，http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Con示例1（请注意“ string [] ...”的位置）：
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
贝尔维尤
设计目标：
- 将HTML视为一流的语言，而不是将其视为“纯文本”。
- 不要搞乱我的HTML！数据绑定代码（Bellevue代码）应与HTML分开。
- 强制严格的模型视图分离
抄网
设计目标：
Brail视图引擎已从MonoRail移植到Microsoft ASP.NET MVC框架。有关Brail的介绍，请参见Castle项目网站上的文档。
优点：
- 仿照“手腕友好的python语法”
- 按需编译视图（但没有可用的预编译）
缺点：
例：
<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使用VB.NET的XML文字，而不是像大多数其他视图引擎一样使用字符串。
优点：
- 有效XML的编译时检查
- 语法着色
- 全面智能
- 编译视图
- 使用常规CLR类，函数等的可扩展性
- 无缝的可组合性和可操作性，因为它是常规的VB.NET代码
- 可单元测试
缺点：
例：
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango的
设计目标：
NDjango是使用F＃语言在.NET平台上实现Django模板语言的实现
。
优点：
纳姆
设计目标：
Rails视图引擎的.NET端口。从Haml网站：
Haml是一种标记语言，用于简洁地描述任何Web文档的XHTML，而无需使用内联代码... Haml避免了将XHTML显式编码到模板中的需要，因为它实际上是XHTML的抽象描述，并带有一些代码来生成动态内容。
优点：
缺点：
- XHTML的抽象，而不是利用标记的熟悉性
- VS2010没有Intellisense
例：
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine（MvcContrib）
设计目标：
一个基于NVelocity的视图引擎，
它是流行的Java项目Velocity的.NET端口
。
优点：
缺点：
- 视图上可用的辅助方法数量有限
- 不自动具有Visual Studio集成（IntelliSense，视图的编译时检查或重构）
例：
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
夏普瓷砖
设计目标：
SharpTiles是JSTL的部分移植版，
结合了Tiles框架（从Mile stone 1开始）的概念。
优点：
缺点：
例：
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark View引擎
设计目标：
这个想法是让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视图引擎MVC
设计目标：
- 轻巧。没有创建页面类。
- 快速。模板被写入响应输出流。
- 已缓存。模板被缓存，但是利用FileSystemWatcher来检测文件更改。
- 动态。模板可以用代码即时生成。
- 灵活。模板可以嵌套到任何级别。
- 符合MVC原则。促进UI和业务逻辑的分离。所有数据都是提前创建的，并向下传递到模板。
优点：
- StringTemplate Java开发人员熟悉
缺点：
翼节拍
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不太实用）。