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:
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:
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).