web-dev-qa-db-fra.com

Comparaison du moteur de vue ASP.NET MVC

J'ai consulté sur SO & Google pour une liste détaillée des différents moteurs de visualisation disponibles pour ASP.NET MVC, mais je n'ai pas trouvé beaucoup plus que de simples descriptions de haut niveau de ce qu'est un moteur de visualisation.

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

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

337
mckamey

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

Puisqu'une liste complète ne semble pas exister, commençons-en une ici sur SO. Cela peut être d'une grande utilité pour la communauté ASP.NET MVC si les personnes ajoutent leur expérience (en particulier à ceux qui ont contribué à l'une de celles-ci). Tout ce qui implémente IViewEngine (par exemple VirtualPathProviderViewEngine) est un jeu juste ici. Alphabétisez simplement les nouveaux moteurs de vue (en laissant WebFormViewEngine et Razor en haut) et essayez d’être objectif dans les comparaisons.


System.Web.Mvc.WebFormViewEngine

Objectifs de conception:

Un moteur de vue utilisé pour rendre une page Web Forms à la réponse.

Avantages:

  • omniprésent puisqu'il est livré avec ASP.NET MVC
  • expérience familière pour les développeurs ASP.NET
  • IntelliSense
  • pouvez choisir n’importe quelle langue avec un fournisseur CodeDom (par exemple, C #, VB.NET, F #, Boo, Nemerle)
  • compilation à la demande ou précompilé vues

Les inconvénients:

  • l'utilisation est perturbée par l'existence de modèles "classiques ASP.NET" qui ne s'appliquent plus dans MVC (ViewState PostBack, par exemple)
  • peut contribuer à l'anti-pattern de "tag soup"
  • la syntaxe de bloc de code et le typage fort peuvent gêner
  • IntelliSense applique un style pas toujours approprié pour les blocs de code en ligne
  • peut être bruyant lors de la conception de 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 conception:

Avantages:

  • Compact, expressif et fluide
  • Facile à apprendre
  • N'est pas une nouvelle langue
  • A un grand Intellisense
  • Unité testable
  • Omniprésent, livré avec ASP.NET MVC

Les inconvénients:

  • Crée un problème légèrement différent de "tag soup" référencé ci-dessus. Lorsque les balises de serveur fournissent en réalité une structure autour du code serveur et du code non serveur, Razor confond le code HTML et le code serveur, ce qui rend difficile le développement HTML pur ou JS (voir Exemple 1 de con), car vous devez "échapper" au code HTML et/ou JavaScript. balises dans certaines conditions très courantes.
  • Encapsulation médiocre + possibilité de réutilisation: appeler un modèle de rasoir comme s'il s'agissait d'une méthode normale - dans la pratique, rasoir peut appeler du code, mais pas l'inverse, ce qui peut encourager le mélange de code et de présentation.
  • La syntaxe est très orientée HTML. générer du contenu non-HTML peut être délicat. Malgré cela, le modèle de données de rasoir est essentiellement une simple concaténation de chaînes. Les erreurs de syntaxe et d'imbrication ne sont donc ni détectées de manière statique ni dynamique, bien que l'aide de VS.NET au moment du design permette de l'atténuer quelque peu. La maintenabilité et la refactorabilité peuvent en souffrir.
  • Aucune API documentée, http://msdn.Microsoft.com/en-us/library/system.web.razor.aspx

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

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

Bellevue

Objectifs de conception:

  • Respectez le langage HTML en tant que langage de première classe, au lieu de le traiter comme "juste du texte".
  • Ne plaisante pas avec mon HTML! Le code de liaison de données (code Bellevue) doit être séparé du code HTML.
  • Appliquer une séparation modèle-vue stricte

Brail

Objectifs de conception:

Le moteur de visualisation Brail a été porté à partir de MonoRail pour fonctionner avec Microsoft ASP.NET MVC Framework. Pour une introduction à Brail, voir la documentation sur le site Web du projet Castle .

Avantages:

  • modélisé selon "la syntaxe python adaptée aux poignets"
  • Vues compilées à la demande (mais pas de précompilation disponible)

Les inconvénients:

  • conçu pour être écrit dans le langage Boo

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:

  • Vérification à la compilation de XML valide
  • Coloration de la syntaxe
  • Plein intellisense
  • Vues compilées
  • Extensibilité à l'aide de classes, fonctions, etc. CLR classiques
  • Compossabilité et manipulation sans faille puisqu'il s'agit d'un code VB.NET standard
  • Unité testable

Les inconvénients:

  • Performances: construit l'ensemble du 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 conception:

NDjango est une implémentation de Django Template Language sur la plate-forme .NET, à l'aide du langage F # .

Avantages:


NHaml

Objectifs de conception:

Port .NET du moteur de vue Haml Rails. De le site web de Haml :

Haml est un langage de balisage utilisé pour décrire proprement et simplement le XHTML de tout document Web, sans utiliser de code en ligne ... Haml évite de coder explicitement XHTML dans le modèle, car il s'agit en fait d'une description abstraite du XHTML. , avec du code pour générer du contenu dynamique.

Avantages:

  • structure laconique (par exemple, D.R.Y.)
  • bien en retrait
  • structure claire
  • C # Intellisense (pour VS2008 sans ReSharper)

Les inconvénients:

  • une abstraction de XHTML plutôt que de tirer parti de la familiarité du balisage
  • Pas d'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 conception:

Un moteur de vue basé sur NVelocity qui est un port .NET du projet Java très répandu Velocity .

Avantages:

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

Les inconvénients:

  • nombre limité de méthodes d'assistance disponibles sur la vue
  • n'a pas automatiquement l'intégration de Visual Studio (IntelliSense, vérification des vues au moment de la compilation 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 conception:

SharpTiles est un port partiel de JSTL combiné avec le concept derrière le cadre de tuiles (à partir de Mile stone 1).

Avantages:

  • familier aux développeurs Java
  • Blocs de code de style XML

Les inconvénients:

  • ...

Exemple:

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

moteur Spark View

Objectifs de conception:

L'idée est de permettre au code HTML de dominer le flux et au code de s'adapter parfaitement.

Avantages:

Les inconvénients:

  • Pas de séparation claire entre la logique du modèle et le balisage littéral (ceci peut être atténué par les préfixes d'espace de nom)

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>

MVC de StringTemplate View Engine

Objectifs de conception:

  • Poids léger. Aucune classe de page n'est créée.
  • Vite. Les modèles sont écrits dans le flux de sortie de réponse.
  • En cache. Les modèles sont mis en cache, mais utilisent FileSystemWatcher pour détecter les modifications de fichier.
  • Dynamique. Les modèles peuvent être générés à la volée dans le code.
  • Souple. Les modèles peuvent être imbriqués à n'importe quel niveau.
  • Conformément aux principes de MVC. Favorise la séparation de l'interface utilisateur et de la logique métier. Toutes les données sont créées à l'avance et transmises au modèle.

Avantages:

  • familier aux développeurs de StringTemplate Java

Les inconvénients:

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

Battements d'ailes

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

Avantages:

  • Vérification à la compilation de XML valide
  • Coloration de la syntaxe
  • Plein intellisense
  • Vues compilées
  • Extensibilité à l'aide de classes, fonctions, etc. CLR classiques
  • Compossabilité et manipulation sans faille puisqu'il s'agit d'un code F # standard
  • Unité testable

Les inconvénients:

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

XsltViewEngine (MvcContrib)

Objectifs de conception:

Construit des vues à partir de XSLT familier

Avantages:

  • largement répandu
  • langage de template familier pour les développeurs XML
  • Basé sur XML
  • testé dans le temps
  • Les erreurs de syntaxe et d'imbrication d'éléments peuvent être détectées de manière statique.

Les inconvénients:

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

428
mckamey

Mon choix actuel est Razor. Il est très propre et facile à lire et maintient les pages de vue très faciles à maintenir. Il y a aussi le support intellisense qui est vraiment génial. ALos, quand il est utilisé avec des assistants Web, il est également très 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 voila. C'est très propre et facile à lire. Certes, c’est un exemple simple, mais même sur des pages et des formulaires complexes, il est toujours très facile à lire et à comprendre.

Quant aux inconvénients? Jusqu’à présent (pour la première fois, je suis novice), lors de l’utilisation de certains des aides pour les formulaires, l’ajout d’une référence de classe CSS est un peu insuffisant, ce qui est un peu gênant.

Merci Nathj07

17
nathj07

Je sais que cela ne répond pas vraiment à votre question, mais différents moteurs de visualisation ont des objectifs différents. Le Spark View Engine , par exemple, vise à vous débarrasser de votre vision de "tag soup" en essayant de tout rendre fluide et lisible.

Votre meilleur choix serait simplement de regarder quelques implémentations. Si cela semble attrayant pour l’intention de votre solution, essayez-le. Vous pouvez combiner les moteurs de vue dans MVC. Cela ne devrait donc pas être un problème si vous décidez de ne pas utiliser un moteur spécifique.

10
MunkiPhD

Vérifiez ceci SharpDOM . Il s’agit d’un dsl interne c # 4.0 permettant de générer du code HTML ainsi que du moteur de vue asp.net mvc.

8
Anton Shelin

J'aime ndjango . Il est très facile à utiliser et très flexible. Vous pouvez facilement étendre la fonctionnalité d'affichage avec des étiquettes et des filtres personnalisés. Je pense que "fortement lié à F #" est plutôt un avantage qu'un désavantage.

5
rdovhan

Je pense que cette liste devrait également inclure des exemples de chaque moteur d'affichage afin que les utilisateurs puissent en avoir une idée sans avoir à visiter chaque site Web.

Les images indiquent un millier de mots et les exemples de balises sont comme des captures d'écran des moteurs de visualisation :) Alors, voici l'une de mes préférées moteur d'affichage Spark

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