ASP.NET MVC Ver motor de comparación

He estado buscando en SO y Google un desglose de los diversos motores de visualización disponibles para ASP.NET MVC, pero no he encontrado mucho más que simples descripciones de alto nivel de lo que es un motor de visualización.

No busco necesariamente el "mejor" o el "más rápido", sino algunas comparaciones del mundo real de las ventajas / desventajas de los principales jugadores (por ejemplo, el WebFormViewEngine predeterminado, MvcContrib View Engines, etc.) para diversas situaciones. Creo que esto sería realmente útil para determinar si cambiar del motor predeterminado sería ventajoso para un proyecto o grupo de desarrollo dado.

¿Alguien ha encontrado tal comparación?

ASP.NET MVC View Engines (Wiki de la comunidad)

Como no parece existir una lista completa, comencemos una aquí en SO. Esto puede ser de gran valor para la comunidad ASP.NET MVC si las personas agregan su experiencia (especialmente cualquiera que haya contribuido a uno de estos). Cualquier implementación IViewEngine(por ejemplo VirtualPathProviderViewEngine) es un juego justo aquí. Simplemente alfabetice los nuevos motores de visualización (dejando WebFormViewEngine y Razor en la parte superior) e intente ser objetivo en las comparaciones.

System.Web.Mvc.WebFormViewEngine

Metas de diseño:

Un motor de vista que se utiliza para representar una página de formularios web en la respuesta.

Pros:

• ubicuo ya que se envía con ASP.NET MVC
• experiencia familiar para desarrolladores ASP.NET
• IntelliSense
• puede elegir cualquier idioma con un proveedor de CodeDom (por ejemplo, C #, VB.NET, F #, Boo, Nemerle)
• compilación bajo demanda o vistas precompiladas

Contras:

• el uso se confunde con la existencia de patrones "ASP.NET clásicos" que ya no se aplican en MVC (por ejemplo, ViewState PostBack)
• puede contribuir al antipatrón de "sopa de etiqueta"
• la sintaxis de bloque de código y la escritura fuerte pueden interferir
• IntelliSense aplica el estilo no siempre apropiado para bloques de código en línea
• puede ser ruidoso al diseñar plantillas simples

Ejemplo:

<%@ 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

Metas de diseño:

Pros:

• Compacto, expresivo y fluido.
• Fácil de aprender
• No es un idioma nuevo
• Tiene gran Intellisense
• Unidad comprobable
• Ubicuo, se envía con ASP.NET MVC

Contras:

• Crea un problema ligeramente diferente de la "etiqueta de sopa" mencionada anteriormente. Cuando las etiquetas del servidor realmente proporcionan una estructura en torno al código del servidor y del servidor, Razor confunde HTML y el código del servidor, lo que dificulta el desarrollo de HTML o JS puro (consulte el ejemplo 1 de Con), ya que tiene que "escapar" de HTML y / o JavaScript etiquetas bajo ciertas condiciones muy comunes.
• Encapsulación pobre + reutilización: no es práctico llamar a una plantilla de afeitadora como si fuera un método normal; en la práctica, la afeitadora puede llamar a código pero no al revés, lo que puede fomentar la mezcla de código y presentación.
• La sintaxis está muy orientada a html; generar contenido no html puede ser complicado. A pesar de esto, el modelo de datos de la maquinilla de afeitar es esencialmente una concatenación de cadenas, por lo que los errores de sintaxis y anidación no se detectan estática ni dinámicamente, aunque el tiempo de diseño de VS.NET ayuda a mitigar esto de alguna manera. La mantenibilidad y la refactorabilidad pueden sufrir debido a esto.
• Sin API documentada , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Ejemplo # 1 (observe la ubicación de "string [] ..."):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

Bellevue

Metas de diseño:

• Respete HTML como lenguaje de primera clase en lugar de tratarlo como "solo texto".
• ¡No te metas con mi HTML! El código de enlace de datos (código Bellevue) debe estar separado del HTML.
• Hacer cumplir una estricta separación de vista de modelo

Candaliza

Metas de diseño:

El motor de vista Brail ha sido portado desde MonoRail para trabajar con el Marco MVC de Microsoft ASP.NET. Para una introducción a Brail, consulte la documentación en el sitio web del proyecto Castle .

Pros:

• modelado a partir de la "sintaxis de Python amigable con la muñeca"
• Vistas compiladas bajo demanda (pero no hay precompilación disponible)

Contras:

• diseñado para ser escrito en el idioma Boo

Ejemplo:

<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 usa los literales XML de VB.NET en lugar de cadenas como la mayoría de los otros motores de vista.

Pros:

• Comprobación en tiempo de compilación de XML válido
• Coloración de sintaxis
• Intellisense completo
• Vistas compiladas
• Extensibilidad usando clases regulares de CLR, funciones, etc.
• Fácil de componer y manipular, ya que es un código VB.NET normal
• Unidad comprobable

Contras:

• Rendimiento: construye todo el DOM antes de enviarlo al cliente.

Ejemplo:

Protected Overrides Function Body() As XElement
    Return _
    <body>
        <h1>Hello, World</h1>
    </body>
End Function

NDjango

Metas de diseño:

NDjango es una implementación del lenguaje de plantillas Django en la plataforma .NET, utilizando el lenguaje F # .

Pros:

• La versión 0.9.1.0 de NDjango parece ser más estable bajo estrés que WebFormViewEngine
• Django Template Editor con colorización de sintaxis, finalización de código y diagnósticos a medida que escribe (solo VS2010)
• Integrado con los marcos ASP.NET, Castle MonoRail y Bistro MVC

NHaml

Metas de diseño:

Puerto .NET de Rails Haml view engine. Desde el sitio web de Haml :

Haml es un lenguaje de marcado que se usa para describir de manera limpia y simple el XHTML de cualquier documento web, sin el uso de código en línea ... Haml evita la necesidad de codificar explícitamente XHTML en la plantilla, porque en realidad es una descripción abstracta del XHTML , con algo de código para generar contenido dinámico.

Pros:

• estructura concisa (es decir, SECO)
• bien sangrado
• estructura clara
• C # Intellisense (para VS2008 sin ReSharper)

Contras:

• una abstracción de XHTML en lugar de aprovechar la familiaridad del marcado
• Sin Intellisense para VS2010

Ejemplo:

@type=IEnumerable<Product>
- if(model.Any())
  %ul
    - foreach (var p in model)
      %li= p.Name
- else
  %p No products available

NVelocityViewEngine (MvcContrib)

Metas de diseño:

Un motor de visualización basado en NVelocity, que es un puerto .NET del popular proyecto Java Velocity .

Pros:

• fácil de leer / escribir
• código de vista conciso

Contras:

• número limitado de métodos auxiliares disponibles en la vista
• no tiene automáticamente la integración de Visual Studio (IntelliSense, verificación de vistas en tiempo de compilación o refactorización)

Ejemplo:

#foreach ($p in $viewdata.Model)
#beforeall
    <ul>
#each
    <li>$p.Name</li>
#afterall
    </ul>
#nodata 
    <p>No products available</p>
#end

SharpTiles

Metas de diseño:

SharpTiles es un puerto parcial de JSTL combinado con el concepto detrás del marco de Tiles (a partir de Mile stone 1).

Pros:

• familiar para los desarrolladores de Java
• Bloques de código de estilo XML

Contras:

• ...

Ejemplo:

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

Spark View Engine

Metas de diseño:

La idea es permitir que el html domine el flujo y que el código se ajuste sin problemas.

Pros:

• Produce plantillas más legibles
• C # Intellisense (para VS2008 sin ReSharper)
• Complemento SparkSense para VS2010 (funciona con ReSharper)
• Proporciona una poderosa característica de enlaces para deshacerse de todo el código en sus vistas y le permite inventar fácilmente sus propias etiquetas HTML

Contras:

• No hay una separación clara de la lógica de la plantilla del marcado literal (esto puede mitigarse mediante prefijos de espacio de nombres)

Ejemplo:

<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

Metas de diseño:

• Ligero. No se crean clases de página.
• Rápido. Las plantillas se escriben en la secuencia de salida de respuesta.
• En caché Las plantillas se almacenan en caché, pero utilizan un FileSystemWatcher para detectar cambios en los archivos.
• Dinámica. Se pueden generar plantillas sobre la marcha en código.
• Flexible. Las plantillas se pueden anidar a cualquier nivel.
• En línea con los principios MVC. Promueve la separación de UI y Business Logic. Todos los datos se crean con anticipación y se pasan a la plantilla.

Pros:

• familiar para los desarrolladores de Java StringTemplate

Contras:

• la sintaxis de plantilla simplista puede interferir con la salida prevista (por ejemplo, conflicto jQuery )

Wing Beats

Wing Beats es un DSL interno para crear XHTML. Se basa en F # e incluye un motor de vista ASP.NET MVC, pero también se puede usar únicamente por su capacidad de crear XHTML.

Pros:

• Comprobación en tiempo de compilación de XML válido
• Coloración de sintaxis
• Intellisense completo
• Vistas compiladas
• Extensibilidad usando clases regulares de CLR, funciones, etc.
• Fácil de componer y manipular, ya que es un código F # normal
• Unidad comprobable

Contras:

• Realmente no escribes HTML, sino un código que representa HTML en un DSL.

XsltViewEngine (MvcContrib)

Metas de diseño:

Crea vistas desde XSLT familiar

Pros:

• ampliamente ubicuo
• lenguaje de plantillas familiar para desarrolladores XML
• Basado en XML
• probado en el tiempo
• Los errores de sintaxis y anidamiento de elementos pueden detectarse estáticamente.

Contras:

• El estilo de lenguaje funcional dificulta el control de flujo
• XSLT 2.0 (¿probablemente?) No es compatible. (XSLT 1.0 es mucho menos práctico).

Mi elección actual es Razor. Es muy limpio y fácil de leer y mantiene las páginas de vista muy fáciles de mantener. También hay soporte intellisense que es realmente genial. También, cuando se usa con ayudantes web, también es realmente poderoso.

Para proporcionar una muestra simple:

@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>

Y ahí lo tienes. Eso es muy limpio y fácil de leer. De acuerdo, ese es un ejemplo simple, pero incluso en páginas y formularios complejos sigue siendo muy fácil de leer y comprender.

En cuanto a los contras? Bueno, hasta ahora (soy nuevo en esto) cuando uso algunos de los ayudantes para formularios, hay una falta de soporte para agregar una referencia de clase CSS que es un poco molesto.

Gracias Nathj07

Sé que esto realmente no responde a su pregunta, pero diferentes motores de visualización tienen diferentes propósitos. La chispa del motor Ver , por ejemplo, busca deshacerse de sus puntos de vista "sopa etiqueta" tratando de hacer todo lo fluida y fácil de leer.

Su mejor opción sería mirar algunas implementaciones. Si parece atractivo para la intención de su solución, pruébelo. Puede mezclar y combinar motores de vista en MVC, por lo que no debería ser un problema si decide no utilizar un motor específico.

Comprueba este SharpDOM . Este es un dsl interno ac # 4.0 para generar html y también asp.net mvc view engine.

Me gusta ndjango . Es muy fácil de usar y muy flexible. Puede ampliar fácilmente la funcionalidad de visualización con etiquetas y filtros personalizados. Creo que "muy ligado a F #" es más bien una ventaja que una desventaja.

Creo que esta lista también debe incluir ejemplos de cada motor de visualización para que los usuarios puedan obtener una muestra de cada uno sin tener que visitar cada sitio web.

Las imágenes dicen más que mil palabras y las muestras de marcas son como capturas de pantalla para ver motores :) Así que aquí hay una de mi Spark View Engine favorito

<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>