ASP.NET MVC视图引擎比较

mck*_*mey 338 asp.net-mvc viewengine spark-view-engine razor

我一直在搜索SO和Google,了解可用于ASP.NET MVC的各种视图引擎,但是没有找到比视图引擎的简单高级描述更多的内容.

我不一定在寻找"最佳"或"最快",而是在各种情况下对主要参与者(例如默认的WebFormViewEngine,MvcContrib View Engines等)的优缺点进行实际比较.我认为这对确定从默认引擎切换是否对给定项目或开发组有利有用.

有没有人遇到这样的比较?

mck*_*mey 429

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)
  • 按需编译或预编译视图

缺点:

  • 因为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>
<%}%>
Run Code Online (Sandbox Code Playgroud)

System.Web.Razor

设计目标:

优点:

  • 紧凑,富有表现力和流畅性
  • 简单易学
  • 不是一门新语言
  • 有很棒的Intellisense
  • 单元可测试
  • 无处不在,附带ASP.NET MVC

缺点:

  • 从上面引用的"标签汤"创建一个稍微不同的问题.服务器标签实际上提供服务器和非服务器代码的结构,Razor混淆HTML和服务器代码,使纯HTML或JS开发具有挑战性(参见例1),因为你最终必须"逃避"HTML和/或JavaScript在某些非常常见的条件下标记.
  • 封装不良+可重用性:将剃刀模板称为普通方法是不切实际的 - 实际上剃刀可以调用代码但反之亦然,这可能会鼓励代码和表示混合.
  • 语法非常面向html; 生成非HTML内容可能很棘手.尽管如此,razor的数据模型本质上只是字符串连接,因此语法和嵌套错误既不是静态也不是动态检测,尽管VS.NET设计时有助于缓解这种情况.由此可维护性和可重构性可能受到影响.
  • 没有记录的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>
    }
}
Run Code Online (Sandbox Code Playgroud)

贝尔维尤

设计目标:

  • 将HTML视为一流语言,而不是将其视为"只是文本".
  • 不要乱用我的HTML!数据绑定代码(Bellevue代码)应与HTML分开.
  • 实施严格的模型 - 视图分离

抄网

设计目标:

Brail视图引擎已从MonoRail移植到Microsoft ASP.NET MVC框架.有关Brail的介绍,请参阅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>
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

NDjango

设计目标:

NDjango是使用F#语言在.NET平台上实现 Django模板语言.

优点:


NHaml

设计目标:

Rails Haml视图引擎的.NET端口.来自Haml网站:

Haml是一种标记语言,用于干净简单地描述任何Web文档的XHTML,而不使用内联代码...... Haml避免了将XHTML显式编码到模板中的需要,因为它实际上是XHTML的抽象描述,用一些代码来生成动态内容.

优点:

  • 简洁结构(即DRY)
  • 缩进
  • 结构清晰
  • 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
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

SharpTiles

设计目标:

SharpTiles是JSTL的部分端口, 结合了Tiles框架背后的概念(从Mile stone 1开始).

优点:

  • 熟悉Java开发人员
  • XML样式的代码块

缺点:

  • ...

例:

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>
Run Code Online (Sandbox Code Playgroud)

Spark视图引擎

设计目标:

这个想法是允许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>
Run Code Online (Sandbox Code Playgroud)

StringTemplate视图引擎MVC

设计目标:

  • 轻巧.没有创建页面类.
  • 快速.模板将写入响应输出流.
  • 缓存.模板已缓存,但使用FileSystemWatcher检测文件更改.
  • 动态.模板可以在代码中动态生成.
  • 灵活.模板可以嵌套到任何级别.
  • 符合MVC原则.促进UI和业务逻辑的分离.所有数据都是提前创建的,并传递给模板.

优点:

  • 熟悉StringTemplate Java开发人员

缺点:

  • 简化模板语法可能会干扰预期的输出(例如jQuery冲突)

翼节拍

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不太实用).

  • @Owen:是的.您必须从C#开发人员的角度来看待这一点.您不想仅仅使用模板引擎来学习另一种语言.(自然如果你已经知道Boo,那很酷,但对于大多数C#开发人员来说,这是一个需要克服的额外障碍) (48认同)
  • @ BrianLy:因为F#是编译和功能的,这意味着它与运行时的其余部分(至少直到c#4)更快,更具互操作性,并且是幂等的.我们一开始就沿着铁路线走下去,但对结果并不满意.至于命名 - 我们愿意接受建议:) (9认同)
  • 由于Brail的Cons部分,投票结束.以Boo为语言肯定不是骗局. (7认同)
  • 剃刀在那里.它应该更新为按字母顺序Razor. (5认同)
  • Boo是Pro,而不是Con.你已经在C#之外,模板可以变得越来越好.C#并不意味着在"模板"环境中使用,它有点表达但不是"手腕友好".另一方面,BOO的创建考虑到了这一点,因此它更适合在模板环境中使用. (3认同)
  • 为什么NDjango使用F#而不是IronPython?似乎缺乏关于命名的想象力.是不是只能移植Python版本?我知道IronPython已经能够运行部分Django一段时间了. (2认同)
  • 但是,由于这种单一的意见分歧,将这个答案投下来肯定是不公平的......很棒的答案! (2认同)

nat*_*j07 17

我目前的选择是Razor.它非常干净,易于阅读,并使视图页面易于维护.还有intellisense支持,这真的很棒.ALO,当与web帮助器一起使用时,它也非常强大.

提供一个简单的样本:

@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>
Run Code Online (Sandbox Code Playgroud)

你有它.这非常干净,易于阅读.当然,这是一个简单的例子,但即使在复杂的页面和表单上,它仍然很容易阅读和理解.

至于缺点?到目前为止(我是新手)当使用表单的一些助手时,缺乏对添加CSS类引用的支持,这有点烦人.

谢谢Nathj07


Mun*_*PhD 10

我知道这并没有真正回答你的问题,但不同的View引擎有不同的用途.在星火视图引擎,例如,旨在通过努力让一切流畅性和可读性,以摆脱你的"标签汤"的观点.

你最好的选择就是看一些实现.如果它看起来对您的解决方案的意图很有吸引力,请尝试一下.您可以在MVC中混合和匹配视图引擎,因此如果您决定不使用特定引擎,则不应该成为问题.


Ant*_*lin 8

检查这个SharpDOM.这是用于生成html和asp.net mvc视图引擎的ac#4.0内部dsl.


小智 5

我喜欢ndjango.它非常易于使用且非常灵活.您可以使用自定义标记和过滤器轻松扩展视图功能.我认为"与F#有很大关系"比缺点更有优势.