Comparação do mecanismo de exibição do ASP.NET MVC

Estive pesquisando no SO e no Google uma análise dos vários mecanismos de exibição disponíveis para o ASP.NET MVC, mas não encontrei muito mais do que simples descrições de alto nível do que é um mecanismo de exibição.

Não estou necessariamente procurando por "melhor" ou "mais rápido", mas por algumas comparações no mundo real de vantagens / desvantagens dos principais players (por exemplo, o WebFormViewEngine padrão, o MvcContrib View Engines etc.) para várias situações. Eu acho que isso seria realmente útil para determinar se a troca do mecanismo padrão seria vantajosa para um determinado projeto ou grupo de desenvolvimento.

Alguém já encontrou essa comparação?

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:

• A versão 0.9.1.0 do NDjango parece ser mais estável sob estresse do que WebFormViewEngine
• Editor de modelos do Django com coloração de sintaxe, conclusão de código e diagnóstico conforme você digita (somente VS2010)
• Integrado com as estruturas ASP.NET, Castle MonoRail e Bistro MVC

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

Minha escolha atual é Razor. É muito limpo e fácil de ler e mantém as páginas de visualização muito fáceis de manter. Há também um suporte inteligente que é realmente ótimo. Além disso, quando usado com assistentes da Web, também é realmente poderoso.

Para fornecer uma amostra simples:

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

E aí está. Isso é muito limpo e fácil de ler. É um exemplo simples, mas mesmo em páginas e formulários complexos ainda é muito fácil de ler e entender.

Quanto aos contras? Bem, até agora (eu sou novo nisso) ao usar alguns dos auxiliares para formulários, há uma falta de suporte para adicionar uma referência de classe CSS, o que é um pouco chato.

Obrigado Nathj07

Sei que isso realmente não responde à sua pergunta, mas diferentes mecanismos de exibição têm finalidades diferentes. O mecanismo de exibição Spark , por exemplo, tem como objetivo livrar suas visualizações da "tag soup", tentando tornar tudo fluente e legível.

Sua melhor aposta seria apenas olhar para algumas implementações. Se parecer atraente para a intenção da sua solução, experimente. Você pode misturar e combinar os mecanismos de exibição no MVC, portanto, isso não deve ser um problema se você decidir não usar um mecanismo específico.

Verifique este SharpDOM . Este é um dsl interno do AC # 4.0 para gerar html e também o mecanismo de exibição asp.net mvc.

Eu gosto de ndjango . É muito fácil de usar e muito flexível. Você pode estender facilmente a funcionalidade de visualização com tags e filtros personalizados. Eu acho que "muito ligado ao F #" é mais uma vantagem do que uma desvantagem.

Acho que essa lista também deve incluir exemplos de cada mecanismo de exibição, para que os usuários possam ter uma ideia de cada um sem precisar visitar todos os sites.

As imagens dizem mais que mil palavras e exemplos de marcação são como capturas de tela para os mecanismos de exibição :) Então, aqui está uma do meu 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>