我一直在SO &谷歌上搜索ASP可用的各种视图引擎的分类。NET MVC，但没有发现更多的简单的高级描述什么是视图引擎。
我并不一定是在寻找“最好”或“最快”，而是在各种情况下对主要玩家(例如默认的WebFormViewEngine, MvcContrib视图引擎等)的优点/缺点进行一些真实世界的比较。我认为这将有助于确定从默认引擎切换是否对给定的项目或开发组有利。
有人遇到过这样的比较吗?
当前回答
ASP。NET MVC视图引擎(社区Wiki)
由于似乎不存在一个全面的列表，让我们从SO开始。这对ASP是很有价值的。NET MVC社区，如果人们添加他们的经验(特别是任何对其中之一做出贡献的人)。任何实现IViewEngine的东西(例如VirtualPathProviderViewEngine)在这里都是公平的。只需按字母顺序排列新的视图引擎(将WebFormViewEngine和Razor留在顶部)，并尝试在比较中保持客观。
System.Web.Mvc.WebFormViewEngine
设计目标:
视图引擎，用于呈现 Web Forms页面的响应。
优点:
它无处不在，因为它与ASP一起发布。NET MVC 熟悉ASP的使用经验。网络开发人员 智能感知 可以选择任何带有CodeDom提供程序的语言(例如c#， VB。NET, f#， Boo, Nemerle) 按需编译或预编译视图
缺点:
“经典的ASP。NET”模式不再适用于MVC(例如ViewState PostBack) 可以促进“标签汤”的反模式 代码块语法和强类型可能会成为障碍 智能感知执行的样式并不总是适合内联代码块 在设计简单模板时是否会有噪声
例子:
<%@ 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
缺点:
Creates a slightly different problem from "tag soup" referenced above. Where the server tags actually provide structure around server and non-server code, Razor confuses HTML and server code, making pure HTML or JS development challenging (see Con Example #1) as you end up having to "escape" HTML and / or JavaScript tags under certain very common conditions. Poor encapsulation+reuseability: It's impractical to call a razor template as if it were a normal method - in practice razor can call code but not vice versa, which can encourage mixing of code and presentation. Syntax is very html-oriented; generating non-html content can be tricky. Despite this, razor's data model is essentially just string-concatenation, so syntax and nesting errors are neither statically nor dynamically detected, though VS.NET design-time help mitigates this somewhat. Maintainability and refactorability can suffer due to this. No documented API, http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
反例#1(注意“string[]…”的位置):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
贝尔维尤
设计目标:
尊重HTML作为一流的语言，而不是把它当作“文本”。 不要乱动我的HTML!数据绑定代码(Bellevue代码)应该与HTML分开。 执行严格的模型-视图分离
卷帆索
设计目标:
Brail视图引擎已经移植 从单轨铁路到与 微软的ASP。NET MVC框架。为 关于巴西语的介绍，请参见 关于Castle项目的文档 的网站。
优点:
模仿“手腕友好的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使用VB。NET的XML文字，而不是像大多数其他视图引擎的字符串。
优点:
有效XML的编译时检查 语法着色 完整的智能感知 编译的观点 使用常规CLR类、函数等的可扩展性 无缝组合和操作，因为它是常规的VB。NET代码 单元测试的
缺点:
性能:在将DOM发送到客户端之前构建整个DOM。
例子:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
设计目标:
的实现 .NET中的Django模板语言 平台，使用f#语言。
优点:
NDjango 0.9.1.0版在压力下似乎比WebFormViewEngine更稳定 Django模板编辑器，支持语法着色、代码完成和as-you-type诊断(仅限VS2010) 与ASP集成。NET、Castle MonoRail和Bistro MVC框架
NHaml
设计目标:
Rails Haml视图引擎的. net端口。 来自Haml网站: Haml是一种标记语言 简洁明了地描述 XHTML的任何web文档，没有 内联代码的使用…Haml避免了 需要显式地将XHTML编码到 模板，因为它实际上 XHTML的抽象描述， 用一些代码生成动态 内容。
优点:
结构简洁(即D.R.Y.) 好缩进 清晰的结构 c#智能感知(用于VS2008没有ReSharper)
缺点:
从XHTML抽象而不是利用熟悉的标记 VS2010没有智能感知
例子:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine(版)
设计目标:
的视图引擎 NVelocity是一个。net端口 流行的Java项目 速度。
优点:
易于读/写 简洁的视图代码
缺点:
视图上可用的辅助方法数量有限 不能自动集成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的部分移植 结合瓷砖背后的概念 框架(从Mile stone 1开始)。
优点:
Java开发人员熟悉 xml风格的代码块
缺点:
.．.
例子:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark视图引擎
设计目标:
这个想法是允许html 控制流程和代码以适应 无缝。
优点:
生成可读性更好的模板 c#智能感知(用于VS2008没有ReSharper) VS2010的SparkSense插件(与ReSharper一起工作) 提供强大的绑定功能，以摆脱视图中的所有代码，并允许您轻松创建自己的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>
视图引擎MVC
设计目标:
轻量级的。不创建页类。 快。模板被写入响应输出流。 缓存。模板被缓存，但利用FileSystemWatcher进行检测 文件更改。 动态的。模板可以在代码中动态生成。 灵活。模板可以嵌套到任何级别。 符合MVC原则。促进UI和业务的分离 逻辑。所有数据都是提前创建的 时间，又传给了模板。
优点:
熟悉StringTemplate Java开发人员
缺点:
简单的模板语法会干扰预期的输出(例如jQuery冲突)
挥动着翅膀
Wing Beats是用于创建XHTML的内部DSL。它基于f#，并包含一个ASP。NET MVC视图引擎，但也可以仅用于其创建XHTML的能力。
优点:
有效XML的编译时检查 语法着色 完整的智能感知 编译的观点 使用常规CLR类、函数等的可扩展性 无缝组合和操作，因为它是常规f#代码 单元测试的
缺点:
您实际上并不是在编写HTML，而是在DSL中编写表示HTML的代码。
XsltViewEngine(版)
设计目标:
从熟悉的XSLT构建视图
优点:
广泛的无处不在 XML开发人员熟悉的模板语言 基于xml的 经过时间考验的 语法和元素嵌套错误可以被静态检测到。
缺点:
函数式语言风格使流控制变得困难 不支持XSLT 2.0(可能?)。(XSLT 1.0就不那么实用了)。
其他回答
我目前的选择是Razor。它非常干净，易于阅读，保持视图页面非常容易维护。还有智能感知支持，这真的很棒。另外，当与网络助手一起使用时，它也非常强大。
提供一个简单的示例:
@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
检查这个SharpDOM。这是一个c# 4.0内部dsl，用于生成html和asp.net mvc视图引擎。
我喜欢姜戈。它非常容易使用和非常灵活。您可以使用自定义标记和过滤器轻松扩展视图功能。我认为“与f#紧密相关”是优势而不是劣势。
我认为这个列表还应该包括每个视图引擎的样本，这样用户就可以在不访问每个网站的情况下了解每个视图引擎。
图片胜过千言万语，标记样本就像视图引擎的截图:)所以这里有一个来自我最喜欢的Spark视图引擎
<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视图引擎(社区Wiki)
由于似乎不存在一个全面的列表，让我们从SO开始。这对ASP是很有价值的。NET MVC社区，如果人们添加他们的经验(特别是任何对其中之一做出贡献的人)。任何实现IViewEngine的东西(例如VirtualPathProviderViewEngine)在这里都是公平的。只需按字母顺序排列新的视图引擎(将WebFormViewEngine和Razor留在顶部)，并尝试在比较中保持客观。
System.Web.Mvc.WebFormViewEngine
设计目标:
视图引擎，用于呈现 Web Forms页面的响应。
优点:
它无处不在，因为它与ASP一起发布。NET MVC 熟悉ASP的使用经验。网络开发人员 智能感知 可以选择任何带有CodeDom提供程序的语言(例如c#， VB。NET, f#， Boo, Nemerle) 按需编译或预编译视图
缺点:
“经典的ASP。NET”模式不再适用于MVC(例如ViewState PostBack) 可以促进“标签汤”的反模式 代码块语法和强类型可能会成为障碍 智能感知执行的样式并不总是适合内联代码块 在设计简单模板时是否会有噪声
例子:
<%@ 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
缺点:
Creates a slightly different problem from "tag soup" referenced above. Where the server tags actually provide structure around server and non-server code, Razor confuses HTML and server code, making pure HTML or JS development challenging (see Con Example #1) as you end up having to "escape" HTML and / or JavaScript tags under certain very common conditions. Poor encapsulation+reuseability: It's impractical to call a razor template as if it were a normal method - in practice razor can call code but not vice versa, which can encourage mixing of code and presentation. Syntax is very html-oriented; generating non-html content can be tricky. Despite this, razor's data model is essentially just string-concatenation, so syntax and nesting errors are neither statically nor dynamically detected, though VS.NET design-time help mitigates this somewhat. Maintainability and refactorability can suffer due to this. No documented API, http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
反例#1(注意“string[]…”的位置):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
贝尔维尤
设计目标:
尊重HTML作为一流的语言，而不是把它当作“文本”。 不要乱动我的HTML!数据绑定代码(Bellevue代码)应该与HTML分开。 执行严格的模型-视图分离
卷帆索
设计目标:
Brail视图引擎已经移植 从单轨铁路到与 微软的ASP。NET MVC框架。为 关于巴西语的介绍，请参见 关于Castle项目的文档 的网站。
优点:
模仿“手腕友好的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使用VB。NET的XML文字，而不是像大多数其他视图引擎的字符串。
优点:
有效XML的编译时检查 语法着色 完整的智能感知 编译的观点 使用常规CLR类、函数等的可扩展性 无缝组合和操作，因为它是常规的VB。NET代码 单元测试的
缺点:
性能:在将DOM发送到客户端之前构建整个DOM。
例子:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
设计目标:
的实现 .NET中的Django模板语言 平台，使用f#语言。
优点:
NDjango 0.9.1.0版在压力下似乎比WebFormViewEngine更稳定 Django模板编辑器，支持语法着色、代码完成和as-you-type诊断(仅限VS2010) 与ASP集成。NET、Castle MonoRail和Bistro MVC框架
NHaml
设计目标:
Rails Haml视图引擎的. net端口。 来自Haml网站: Haml是一种标记语言 简洁明了地描述 XHTML的任何web文档，没有 内联代码的使用…Haml避免了 需要显式地将XHTML编码到 模板，因为它实际上 XHTML的抽象描述， 用一些代码生成动态 内容。
优点:
结构简洁(即D.R.Y.) 好缩进 清晰的结构 c#智能感知(用于VS2008没有ReSharper)
缺点:
从XHTML抽象而不是利用熟悉的标记 VS2010没有智能感知
例子:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine(版)
设计目标:
的视图引擎 NVelocity是一个。net端口 流行的Java项目 速度。
优点:
易于读/写 简洁的视图代码
缺点:
视图上可用的辅助方法数量有限 不能自动集成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的部分移植 结合瓷砖背后的概念 框架(从Mile stone 1开始)。
优点:
Java开发人员熟悉 xml风格的代码块
缺点:
.．.
例子:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark视图引擎
设计目标:
这个想法是允许html 控制流程和代码以适应 无缝。
优点:
生成可读性更好的模板 c#智能感知(用于VS2008没有ReSharper) VS2010的SparkSense插件(与ReSharper一起工作) 提供强大的绑定功能，以摆脱视图中的所有代码，并允许您轻松创建自己的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>
视图引擎MVC
设计目标:
轻量级的。不创建页类。 快。模板被写入响应输出流。 缓存。模板被缓存，但利用FileSystemWatcher进行检测 文件更改。 动态的。模板可以在代码中动态生成。 灵活。模板可以嵌套到任何级别。 符合MVC原则。促进UI和业务的分离 逻辑。所有数据都是提前创建的 时间，又传给了模板。
优点:
熟悉StringTemplate Java开发人员
缺点:
简单的模板语法会干扰预期的输出(例如jQuery冲突)
挥动着翅膀
Wing Beats是用于创建XHTML的内部DSL。它基于f#，并包含一个ASP。NET MVC视图引擎，但也可以仅用于其创建XHTML的能力。
优点:
有效XML的编译时检查 语法着色 完整的智能感知 编译的观点 使用常规CLR类、函数等的可扩展性 无缝组合和操作，因为它是常规f#代码 单元测试的
缺点:
您实际上并不是在编写HTML，而是在DSL中编写表示HTML的代码。
XsltViewEngine(版)
设计目标:
从熟悉的XSLT构建视图
优点:
广泛的无处不在 XML开发人员熟悉的模板语言 基于xml的 经过时间考验的 语法和元素嵌套错误可以被静态检测到。
缺点:
函数式语言风格使流控制变得困难 不支持XSLT 2.0(可能?)。(XSLT 1.0就不那么实用了)。
推荐文章
- 剃刀视图抛出“名称‘模型’在当前上下文中不存在”
- HTML按钮调用MVC控制器和动作方法
- ASP。NET MVC 3 Razor:在head标签中包含JavaScript文件
- ViewModel最佳实践
- 使用Html。ActionLink调用不同控制器上的动作
- 有可能制作一个ASP。NET MVC路由基于子域?
- 如何在cshtml模板中创建函数?
- 如何在ASP中处理复选框。NET MVC窗体?
- 什么是@Html。DisplayFor语法?
- 我如何定义一个方法在剃刀?
- 错误:«无法加载类型mvcapapplication»
- 如何从ASP返回200 HTTP状态码。NET MVC 3控制器
- 如何在ASP中找到一个动作的绝对url。净MVC吗?
- @media媒体查询和ASP。NET MVC razor语法冲突
- MVC 4 Razor文件上传
