questions - ASP.NET MVC View Engine Comparison

razor reference

Question

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 necesariamente estoy buscando "lo mejor" o "más rápido", sino más bien algunas comparaciones de ventajas / desventajas de los jugadores principales (p. Ej., El motor predeterminado de WebFormView, MvcContrib View, etc.) para diversas situaciones. Creo que esto sería realmente útil para determinar si el cambio del motor predeterminado sería ventajoso para un determinado proyecto o grupo de desarrollo.

¿Alguien ha encontrado tal comparación?

Answer 1

ASP.NET MVC View Engines (Comunidad Wiki)

Dado que no parece existir una lista completa, comencemos una aquí en SO. Esto puede ser de gran valor para la comunidad MVC de ASP.NET si las personas agregan su experiencia (especialmente cualquiera que haya contribuido a uno de estos). Todo lo que implemente 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), y trate de ser objetivo en las comparaciones.

System.Web.Mvc.WebFormViewEngine

Objetivos de diseño:

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

Pros:

• ubicuo ya que se envía con ASP.NET MVC
• experiencia familiar para los desarrolladores de 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 precompiled .

Contras:

• el uso se confunde por la existencia de patrones "ASP.NET clásicos" que ya no se aplican en MVC (por ejemplo, ViewState PostBack)
• Puede contribuir al anti-patrón de "sopa de etiquetas".
• La sintaxis de bloque de código y la escritura fuerte pueden interferir
• IntelliSense impone un estilo no siempre apropiado para los 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

Objetivos de diseño:

Pros:

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

Contras:

• Crea un problema ligeramente diferente de la "sopa de etiquetas" mencionada anteriormente. Donde las etiquetas del servidor realmente proporcionan una estructura alrededor del código del servidor y del no servidor, Razor confunde el código del servidor y el HTML, lo que hace que el desarrollo de HTML o JS sea difícil (vea el Ejemplo N ° 1) ya que tiene que "escapar" de HTML y / o JavaScript Etiquetas bajo ciertas condiciones muy comunes.
• Mala encapsulación + capacidad de reutilización: no es práctico llamar a una plantilla de maquinilla de afeitar como si fuera un método normal. En la práctica, la máquina de afeitar puede llamar código, pero no al revés, lo que puede fomentar la mezcla de código y presentación.
• La sintaxis es muy orientada a html; generar contenido no html puede ser complicado. A pesar de esto, el modelo de datos de la máquina de afeitar es esencialmente una concatenación de cadenas, por lo que los errores de sintaxis y anidación no se detectan de forma estática ni dinámica, aunque la ayuda en tiempo de diseño de VS.NET mitiga esto de alguna manera. La mantenibilidad y la refactorabilidad pueden sufrir debido a esto.
• No hay API documentada , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

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

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

Bellevue

Objetivos de diseño:

• Respete el 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 la separación estricta de Model-View

Brail

Objetivos de diseño:

El motor de vista de Brail se ha portado desde MonoRail para funcionar con el marco de trabajo de Microsoft ASP.NET MVC. Para una introducción a Brail, vea la documentación en el sitio web del proyecto Castle .

Pros:

• modelado después de "sintaxis de pitón para muñeca"
• Vistas compiladas bajo demanda (pero no hay precompilación disponible)

Contras:

• Diseñado para ser escrito en el lenguaje 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 visualización.

Pros:

• Comprobación en tiempo de compilación de XML válido
• Color de sintaxis
• Intelecto completo
• Vistas compiladas
• Extensibilidad utilizando clases CLR regulares, funciones, etc.
• Compatibilidad y manipulación sin problemas 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

Objetivos 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
• Editor de plantillas Django con color de sintaxis, finalización de código y diagnósticos a medida que se escribe (solo VS2010)
• Integrado con las estructuras ASP.NET, Castle MonoRail y Bistro MVC

NHaml

Objetivos 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 forma limpia y sencilla 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 algún código para generar contenido dinámico.

Pros:

• estructura concisa (es decir, SECA)
• 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)

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

Contras:

• número limitado de métodos de ayuda disponibles en la vista
• no tiene automáticamente la integración de Visual Studio (IntelliSense, verificación 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

Objetivos de diseño:

SharpTiles es un puerto parcial de JSTL combinado con un concepto detrás del marco de Tiles (como en 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

Objetivos de diseño:

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

Pros:

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

Contras:

• No hay una separación clara entre la lógica de la plantilla y el marcado literal (esto puede mitigarse con 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

Objetivos de diseño:

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

Pros:

• familiar para los desarrolladores de StringTemplate Java

Contras:

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

Ala Beats

Wing Beats es un DSL interno para crear XHTML. Se basa en F # e incluye un motor de vista MVC de ASP.NET, 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
• Color de sintaxis
• Intelecto completo
• Vistas compiladas
• Extensibilidad utilizando clases CLR regulares, funciones, etc.
• Compatibilidad y manipulación sin problemas ya que es un código F # regular
• Unidad comprobable

Contras:

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

XsltViewEngine (MvcContrib)

Objetivos de diseño:

Construye 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 de anidamiento de elementos pueden detectarse estáticamente.

Contras:

• El lenguaje funcional hace que el control de flujo sea difícil.
• XSLT 2.0 (¿probablemente?) No es compatible. (XSLT 1.0 es mucho menos práctico).

Answer 2

Compruebe este SharpDOM . Este es un dsl interno ac # 4.0 para generar html y también el motor de visualización mvc de asp.net.

Answer 3

Creo que esta lista también debe incluir muestras de cada motor de visualización para que los usuarios puedan conocer cada una de ellas sin tener que visitar cada sitio web.

Las imágenes dicen que mil palabras y las muestras de marcado son como capturas de pantalla para los motores de visualización :) Así que aquí hay una de mi motor favorito de Spark View

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

Answer 4

Me gusta el 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 una ventaja que una desventaja.

Answer 5

Mi elección actual es Razor. Es muy limpio y fácil de leer y mantiene las páginas de visualización muy fáciles de mantener. También hay soporte intellisense que es realmente grande. Además, 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. Por supuesto, este es un ejemplo simple, pero incluso en páginas y formularios complejos todavía es muy fácil de leer y entender.

En cuanto a los contras? Bueno, hasta ahora (soy nuevo en esto) al usar 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

Answer 6

Sé que esto no responde realmente a tu pregunta, pero los diferentes View Engine tienen diferentes propósitos. El motor Spark View , por ejemplo, pretende eliminar tus puntos de vista de la "sopa de etiquetas" al tratar de hacer que todo sea fluido y legible.

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