Mecanismos de exibição do ASP.NET MVC (Wiki da comunidade)
Como uma lista abrangente parece não existir, vamos começar uma aqui no SO. Isso pode ser de grande valia para a comunidade do ASP.NET MVC se as pessoas adicionarem sua experiência (especialmente quem contribuiu para uma delas). Qualquer coisa que implementar IViewEngine(por exemplo VirtualPathProviderViewEngine) é um jogo justo aqui. Apenas coloque em ordem alfabética os novos View Engines (deixando WebFormViewEngine e Razor no topo) e tente ser objetivo nas comparações.
System.Web.Mvc.WebFormViewEngine
Objetivos do projeto:
Um mecanismo de exibição usado para renderizar uma página de Formulários da Web para a resposta.
Prós:
- onipresente, uma vez que é fornecido com o ASP.NET MVC
- experiência familiar para desenvolvedores do ASP.NET
- IntelliSense
- pode escolher qualquer idioma com um provedor CodeDom (por exemplo, C #, VB.NET, F #, Boo, Nemerle)
- compilação sob demanda ou visualizações pré-compiladas
Contras:
- o uso é confuso pela existência de padrões "clássicos do ASP.NET" que não se aplicam mais ao MVC (por exemplo, ViewState PostBack)
- pode contribuir para o anti-padrão da "sopa de etiquetas"
- sintaxe de bloco de código e digitação forte podem atrapalhar
- O IntelliSense aplica estilo nem sempre apropriado para blocos de código embutido
- pode ser barulhento ao criar modelos simples
Exemplo:
<%@ 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 do projeto:
Prós:
- Compacto, expressivo e fluido
- Fácil de aprender
- Não é um novo idioma
- Possui excelente Intellisense
- Unidade testável
- Onipresente, é fornecido com o ASP.NET MVC
Contras:
- Cria um problema ligeiramente diferente da "sopa de tags" mencionada acima. Onde as tags do servidor realmente fornecem estrutura em torno do código do servidor e do não servidor, o Razor confunde o código do HTML e do servidor, tornando o desenvolvimento de HTML ou JS puro um desafio (consulte o Exemplo de Con # 1) à medida que você acaba "escapando" do HTML e / ou JavaScript tags sob certas condições muito comuns.
- Encapsulamento ruim + reutilização: Não é prático chamar um modelo de barbeador como se fosse um método normal - na prática, o barbeador pode chamar código, mas não vice-versa, o que pode incentivar a mistura de código e apresentação.
- A sintaxe é muito orientada para html; gerar conteúdo não-html pode ser complicado. Apesar disso, o modelo de dados do razor é essencialmente apenas concatenação de strings, portanto, erros de sintaxe e de aninhamento não são estaticamente nem dinamicamente detectados, embora a ajuda em tempo de design do VS.NET atenue um pouco isso. A manutenção e a refatoração podem sofrer devido a isso.
Nenhuma API documentada , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Exemplo de golpe # 1 (observe o posicionamento de "string [] ..."):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
Bellevue
Objetivos do projeto:
- Respeite o HTML como linguagem de primeira classe, em vez de tratá-lo como "apenas texto".
- Não mexa no meu HTML! O código de ligação de dados (código Bellevue) deve ser separado do HTML.
- Impor uma separação estrita da visualização de modelo
Brail
Objetivos do projeto:
O mecanismo de exibição Brail foi portado do MonoRail para funcionar com o Microsoft ASP.NET MVC Framework. Para uma introdução ao Brail, consulte a documentação no site do projeto Castle .
Prós:
- modelado após "sintaxe python compatível com o pulso"
- Visualizações compiladas sob demanda (mas nenhuma pré-compilação disponível)
Contras:
- projetado para ser escrito no idioma Boo
Exemplo:
<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 literais XML do VB.NET em vez de strings, como a maioria dos outros mecanismos de exibição.
Prós:
- Verificação em tempo de compilação de XML válido
- Coloração de sintaxe
- Intensidade total
- Visualizações compiladas
- Extensibilidade usando classes regulares CLR, funções, etc
- Composição e manipulação ininterruptas, já que é código VB.NET normal
- Unidade testável
Contras:
- Desempenho: cria todo o DOM antes de enviá-lo ao cliente.
Exemplo:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
Objetivos do projeto:
NDjango é uma implementação da
Django Template Language na plataforma .NET, usando a linguagem F # .
Prós:
NHaml
Objetivos do projeto:
Porta .NET do mecanismo de exibição do Rails Haml. Do site da Haml :
Haml é uma linguagem de marcação usada para descrever de forma limpa e simples o XHTML de qualquer documento da Web, sem o uso de código embutido ... O Haml evita a necessidade de codificar explicitamente o XHTML no modelo, porque na verdade é uma descrição abstrata do XHTML , com algum código para gerar conteúdo dinâmico.
Prós:
- estrutura concisa (ou seja, SECA)
- bem recuado
- estrutura clara
- C # Intellisense (para VS2008 sem ReSharper)
Contras:
- uma abstração do XHTML em vez de aproveitar a familiaridade da marcação
- No Intellisense para VS2010
Exemplo:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
Objetivos do projeto:
Um mecanismo de exibição baseado no
NVelocity, que é uma porta .NET do popular projeto Java
Velocity .
Prós:
- fácil de ler / escrever
- código de exibição conciso
Contras:
- número limitado de métodos auxiliares disponíveis na visualização
- não possui integração do Visual Studio automaticamente (IntelliSense, verificação de visualizações em tempo de compilação ou refatoração)
Exemplo:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
Objetivos do projeto:
O SharpTiles é uma porta parcial do JSTL
combinada com o conceito por trás da estrutura do Tiles (a partir da pedra Mile 1).
Prós:
- familiar aos desenvolvedores Java
- Blocos de código no estilo XML
Contras:
Exemplo:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Mecanismo de exibição Spark
Objetivos do projeto:
A idéia é permitir que o html domine o fluxo e o código se ajuste perfeitamente.
Prós:
- Produz modelos mais legíveis
- C # Intellisense (para VS2008 sem ReSharper)
- Plug-in SparkSense para VS2010 (funciona com ReSharper)
- Fornece um poderoso recurso de Ligações para se livrar de todo o código em suas visualizações e permite que você invente facilmente suas próprias tags HTML
Contras:
- Nenhuma separação clara da lógica do modelo da marcação literal (isso pode ser atenuado pelos prefixos de namespace)
Exemplo:
<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 do mecanismo de exibição StringTemplate
Objetivos do projeto:
- Leve. Nenhuma classe de página é criada.
- Rápido. Os modelos são gravados no fluxo de Saída de Resposta.
- Em cache. Os modelos são armazenados em cache, mas utilizam um FileSystemWatcher para detectar alterações no arquivo.
- Dinâmico. Os modelos podem ser gerados em tempo real no código.
- Flexível. Os modelos podem ser aninhados em qualquer nível.
- De acordo com os princípios MVC. Promove a separação da interface do usuário e da lógica de negócios. Todos os dados são criados com antecedência e transmitidos ao modelo.
Prós:
- familiar aos desenvolvedores Java StringTemplate
Contras:
- A sintaxe simplista do modelo pode interferir na saída pretendida (por exemplo, conflito do jQuery )
Wing Beats
O Wing Beats é um DSL interno para a criação de XHTML. Ele é baseado no F # e inclui um mecanismo de exibição do ASP.NET MVC, mas também pode ser usado apenas por sua capacidade de criar XHTML.
Prós:
- Verificação em tempo de compilação de XML válido
- Coloração de sintaxe
- Intensidade total
- Visualizações compiladas
- Extensibilidade usando classes regulares CLR, funções, etc
- Composição e manipulação ininterruptas, já que é um código F # regular
- Unidade testável
Contras:
- Você realmente não escreve HTML, mas código que representa HTML em uma DSL.
XsltViewEngine (MvcContrib)
Objetivos do projeto:
Cria visualizações de XSLT familiar
Prós:
- amplamente onipresente
- linguagem de modelo familiar para desenvolvedores de XML
- Baseado em XML
- testado pelo tempo
- Erros de aninhamento de sintaxe e de elemento podem ser detectados estaticamente.
Contras:
- estilo de linguagem funcional dificulta o controle de fluxo
- XSLT 2.0 (provavelmente?) Não é suportado. (XSLT 1.0 é muito menos prático).