我一直在SO &谷歌上搜索ASP可用的各种视图引擎的分类。NET MVC,但没有发现更多的简单的高级描述什么是视图引擎。

我并不一定是在寻找“最好”或“最快”,而是在各种情况下对主要玩家(例如默认的WebFormViewEngine, MvcContrib视图引擎等)的优点/缺点进行一些真实世界的比较。我认为这将有助于确定从默认引擎切换是否对给定的项目或开发组有利。

有人遇到过这样的比较吗?


当前回答

我认为这个列表还应该包括每个视图引擎的样本,这样用户就可以在不访问每个网站的情况下了解每个视图引擎。

图片胜过千言万语,标记样本就像视图引擎的截图:)所以这里有一个来自我最喜欢的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>

其他回答

我认为这个列表还应该包括每个视图引擎的样本,这样用户就可以在不访问每个网站的情况下了解每个视图引擎。

图片胜过千言万语,标记样本就像视图引擎的截图:)所以这里有一个来自我最喜欢的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>

我目前的选择是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

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就不那么实用了)。


我知道这并不能真正回答你的问题,但是不同的视图引擎有不同的目的。例如,Spark视图引擎旨在通过使所有内容流畅且可读来消除视图中的“标签汤”。

最好的办法是只看一些实现。如果它看起来对您的解决方案的意图有吸引力,请尝试一下。你可以在MVC中混合和匹配视图引擎,所以如果你决定不使用特定的引擎,这应该不是一个问题。

我喜欢姜戈。它非常容易使用和非常灵活。您可以使用自定义标记和过滤器轻松扩展视图功能。我认为“与f#紧密相关”是优势而不是劣势。