Question

J'ai été à la recherche sur le SO & Google pour une ventilation des différents moteurs d'affichage disponibles pour ASP.NET MVC, mais ne l'ai pas trouvé beaucoup plus que de simples descriptions de haut niveau de ce qu'est un moteur de vue est.

Je ne cherche pas nécessairement « meilleur » ou « le plus rapide », mais plutôt des comparaisons réelles des avantages / inconvénients des principaux acteurs (par exemple, le WebFormViewEngine par défaut, MvcContrib Voir les moteurs, etc.) pour diverses situations. Je pense que ce serait vraiment utile pour déterminer si le passage du moteur par défaut serait avantageux pour un groupe de projet ou de développement donné.

Quelqu'un at-il rencontré une telle comparaison?

Était-ce utile?

La solution

ASP.NET MVC Voir Engines (Wiki de la communauté)

Comme une liste complète ne semble pas exister, nous allons commencer un ici sur le SO. Cela peut être d'une grande valeur à la communauté ASP.NET MVC si les gens apportent leur expérience (toute personne esp., Qui a contribué à l'un de ces). Tout ce que la mise en œuvre IViewEngine (par exemple VirtualPathProviderViewEngine) est un jeu juste ici. Juste alphabétiser nouveaux moteurs (Voir laissant WebFormViewEngine et rasoir en haut), et essayer d'être objectif dans les comparaisons.


System.Web.Mvc.WebFormViewEngine

Objectifs de la conception:

  

Un moteur de vue qui est utilisé pour rendre un   Page Web Forms à la réponse.

Avantages:

  • omniprésent depuis il est livré avec ASP.NET MVC
  • expérience familière pour les développeurs ASP.NET
  • IntelliSense
  • peut choisir une langue avec un fournisseur de CodeDom (par exemple C #, VB.NET, F #, Boo, Nemerle)
  • compilation sur demande ou vues de précompilés

Moins:

  • utilisation est confondu par l'existence de modèles de "ASP.NET classique", qui ne sont plus applicables dans MVC (par exemple ViewState PostBack)
  • peut contribuer à l'anti-modèle de "soupe tag"
  • syntaxe de code bloc et frappe fort peuvent obtenir de la manière
  • IntelliSense applique un style pas toujours approprié pour les blocs de code en ligne
  • peut être bruyant lors de la conception des modèles simples

Exemple:

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

Objectifs de la conception:

Avantages:

  • Compact, Expressif et fluide
  • Facile à apprendre
  • est-ce pas une nouvelle langue
  • A grand IntelliSense
  • testable
  • ubiquitaire, livré avec ASP.NET MVC

Moins:

  • Crée un problème un peu différent de « soupe de tags » référencé ci-dessus. Lorsque les balises de serveur fournissent effectivement la structure autour serveur et le code non-serveur, Razor brouille le code HTML et du serveur, ce qui rend pur HTML ou le développement JS défi (voir Con Exemple # 1) que vous finissez par avoir à « échapper » HTML et / ou JavaScript balises sous certaines conditions très communes.
  • encapsulation pauvre + réutilisabilité. Il est impossible d'appeler un modèle de rasoir comme si elle était une méthode normale - dans le rasoir pratique peut appeler le code mais pas vice versa, ce qui peut favoriser le mélange du code et la présentation
  • La syntaxe est très orientée html; générer un contenu non-html peut être délicat. Malgré cela, le modèle de données de rasoir est essentiellement juste chaîne de concaténation, de sorte que la syntaxe et les erreurs de nidification ne sont ni statiquement ni détecté de manière dynamique, bien que la conception de l'aide à temps VS.NET atténue ce peu. Maintenabilité et refactorability peuvent souffrir à cause de cela.
  • API Non documenté , http : //msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Exemple # 1 (notez le placement de "string [] ..."):

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

Bellevue

Les objectifs de conception:

  
      
  • Respect HTML comme langue première classe par opposition à le traiter comme « simple texte ».
  •   
  • Ne jouez pas avec mon HTML! Les données code de liaison (code Bellevue) doit être séparé du HTML.
  •   
  • Faire respecter strictement la séparation Model-View
  •   

Brail

Objectifs de la conception:

  

Le moteur de vue Brail a été porté   de monorail à travailler avec le   ASP.NET MVC Framework Microsoft.Pour   une introduction à Brail, voir   la documentation sur le projet Château de la .

Avantages:

  • calqué sur "syntaxe python poignet-friendly"
  • vues compilé sur demande (mais pas précompilation disponible)

Moins:

Exemple:

<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 utilise les littéraux XML de VB.NET au lieu de chaînes comme la plupart des autres moteurs de vue.

Avantages:

  • à la compilation de la vérification XML valide
  • Syntaxe coloration
  • IntelliSense complète
  • vues Compilé
  • Extensibilité en utilisant des classes CLR régulières, fonctions, etc
  • composabilité et manipulation transparente depuis son code régulier VB.NET
  • testable

Moins:

  • Performance: Builds l'ensemble DOM avant de l'envoyer au client.

Exemple:

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

Ndjango

Objectifs de la conception:

  

Ndjango est une mise en œuvre du    Django Template Language sur le .NET   plate-forme, en utilisant le F # langue .

Avantages:


NHaml

Objectifs de la conception:

  

port de Rails .NET moteur vue Haml.   De le site Haml :

     

Haml est un langage de balisage qui est utilisé   à proprement et simplement décrire la   XHTML de tout document web, sans   utilisation du code en ligne ... Haml évite la   besoin pour coder explicitement XHTML dans   le modèle, car il est en fait   une description abstraite du XHTML,   avec un code pour générer dynamique   contenu.

Avantages:

  • Structure lapidaire (à savoir D.R.Y.)
  • bien échancré
  • structure claire
  • C # IntelliSense (pour VS2008 sans ReSharper)

Moins:

  • une abstraction de XHTML plutôt que tirer parti connaissance du balisage
  • Pas IntelliSense pour VS2010

Exemple:

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

NVelocityViewEngine (MvcContrib)

Objectifs de la conception:

  

Un moteur de vue sur la base de    NVelocity qui est un port .NET   du projet Java populaire    Velocity .

Avantages:

  • facile à lire / écrire
  • code de la vue concise

Moins:

  • nombre limité de méthodes d'assistance disponible sur la vue
  • ne pas automatiquement l'intégration de Visual Studio (IntelliSense, compilation vérification des vues ou refactoring)

Exemple:

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

SharpTiles

Objectifs de la conception:

  

SharpTiles est un port partielle de JSTL   combiné avec le concept derrière les    cadre (comme de la pierre Mile 1).

Avantages:

  • familière aux développeurs Java
  • blocs de code de style XML

Moins:

  • ...

Exemple:

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

Spark Voir moteur

Objectifs de la conception:

  

L'idée est de permettre le code html à   dominer le flux et le code pour s'adapter   de façon transparente.

Avantages:

  • modèles plus lisibles Produit des
  • C # IntelliSense (pour VS2008 sans ReSharper)
  • SparkSense plug-in pour VS2010 (fonctionne avec ReSharper)
  • Fournit un puissant disposent pour se débarrasser de tout le code votre point de vue et vous permet d'inventer facilement vos propres balises HTML

Moins:

  • Pas de séparation claire de la logique du modèle de balisage littéral (ce qui peut être atténué par des préfixes d'espaces de noms)

Exemple:

<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 Voir MVC moteur

Objectifs de la conception:

  
      
  • Léger. Pas de cours page sont créés.
  •   
  • rapide. Les modèles sont écrits dans le flux de sortie de réponse.
  •   
  • mises en cache. Les modèles sont mises en cache, mais utilisent un FileSystemWatcher pour détecter   modifications de fichiers.
  •   
  • dynamique. Les modèles peuvent être générés à la volée dans le code.
  •   
  • flexible. Les modèles peuvent être imbriquées à tous les niveaux.
  •   
  • Conformément aux principes MVC. Favorise la séparation de l'interface utilisateur et d'affaires   Logique. Toutes les données sont créées à l'avance   temps et transmis au modèle.
  •   

Avantages:

  • familière aux développeurs Java StringTemplate

Moins:

  • syntaxe du modèle simpliste peut interférer avec la sortie prévue (par exemple conflit jQuery)

Wing Beats

  

Beats Wing est un DSL interne pour la création XHTML. Il est basé sur F # et comprend un moteur vue ASP.NET MVC, mais peut aussi être utilisé uniquement pour sa capacité de créer XHTML.

Avantages:

  • à la compilation de la vérification XML valide
  • Syntaxe coloration
  • IntelliSense complète
  • vues Compilé
  • Extensibilité en utilisant des classes CLR régulières, fonctions, etc
  • composabilité et manipulation transparente car il est un code régulier F #
  • testable

Moins:

  • Vous n'écrivez pas vraiment HTML mais le code HTML qui représente dans un DSL.

XsltViewEngine (MvcContrib)

Objectifs de la conception:

  

Builds vues de XSLT familier

Avantages:

  • largement omniprésente
  • langage familier de modèle pour les développeurs XML
  • XML
  • l'épreuve du temps
  • Syntaxe et les erreurs de nidification éléments peuvent être détectés de manière statique.

Moins:

  • style de langage fonctionnel rend le contrôle de flux difficile
  • XSLT 2.0 est (probablement?) Pas pris en charge. (XSLT 1.0 est mbeaucoup moins pratique).

Autres conseils

Mon choix actuel est Razor. Il est très propre et facile à lire et conserve les pages d'affichage très facile à entretenir. Il y a aussi un soutien IntelliSense qui est vraiment super. Alos, lorsqu'il est utilisé avec des aides web, il est vraiment trop puissant.

Pour fournir un exemple 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>

Et là vous l'avez. C'est très propre et facile à lire. Certes, c'est un exemple simple, mais même sur des pages complexes et forme, il est encore très facile à lire et à comprendre.

En ce qui concerne les inconvénients? Eh bien à ce jour (je suis nouveau à ce sujet) lorsque vous utilisez certaines des aides pour les formulaires, il y a un manque de soutien à l'ajout d'une référence de classe CSS qui est un peu ennuyeux.

Merci Nathj07

Je sais que cela ne répond pas vraiment à votre question, mais différents moteurs View ont des objectifs différents. Spark Voir moteur, par exemple, vise à débarrasser votre point de vue de « soupe de tags » en essayant de tout faire couramment et facile à lire.

Votre meilleur pari serait de simplement regarder certaines implémentations. S'il semble attrayant à l'intention de votre solution, essayer. Vous pouvez mélanger et afficher match moteurs dans MVC, donc il ne devrait pas être un problème si vous décidez de ne pas aller avec un moteur spécifique.

Cochez cette SharpDOM . Ceci est un c # 4.0 dsl interne pour générer html et aussi moteur asp.net vue mvc.

J'aime Ndjango . Il est très facile à utiliser et très flexible. Vous pouvez facilement étendre la fonctionnalité de vue avec des balises et des filtres personnalisés. Je pense que « fortement lié à F # » est plutôt un avantage que désavantage.

Je pense que cette liste devrait également inclure des échantillons de chaque moteur de vue afin que les utilisateurs peuvent obtenir une saveur de chaque sans avoir à visiter chaque site Web.

Des images en disent mille mots et des échantillons de marquage sont comme des captures d'écran pour les moteurs de vue :) Voici donc un de mes préférés rel="nofollow Spark View Engine

<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>
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top