ASP.NET MVC Moteur de vue Razor

Question

Après avoir lu Scott Guthrie L'article du blog de l'UE sur la nouvelle Razor moteur de vue pour ASP.NET MVC et en lisant ceci question en comparant les moteurs de visualisation disponibles.

Razor semble résoudre la plupart des problèmes liés au moteur d'affichage par défaut. Quelles sont les différences de fonctionnalités qui en feraient un choix convaincant pour vous en tant que développeur ? Quelles sont les fonctionnalités manquantes qui vous empêcheraient de l'utiliser ?

Answer 1

Testable à l'unité : Le nouveau moteur de vue prendra en charge la la possibilité de tester les vues à l'unité (sans nécessitant un contrôleur ou un serveur web, et peut être hébergé dans n'importe quel projet de test unitaire de test unitaire - aucun domaine d'application n'est nécessaire).

Enfin ! !! Je n'arrive pas à croire qu'il ait fallu près de 8 ans pour que Microsoft propose enfin un moteur d'affichage qui supporte cela.

Answer 2

Le moteur de visualisation a beaucoup plus à offrir que le langage de balisage. Quelques fonctionnalités de Spark qui vont me manquer :

• écrire des extensions html en utilisant le même langage de balisage, pas le C# (macros) - je vois que Razor supporte aussi cela, j'espère qu'il supporte la surcharge des méthodes/paramètres ;
• balises personnalisées (écrivez _Tag.spark pour utiliser <Tag />) ;
• des variables autogénérées comme varIsFirst, varIndex, etc ;
• les formes d'expression spéciales (?{} pour les attributs conditionnels, $!{} pour ignorer les erreurs, etc) ;
• support agréable des mises en page maître/partiel, y compris la possibilité de spécifier dans le partiel qu'une partie du balisage ne doit être rendue qu'une seule fois dans le maître (par exemple, script includes) ;
• vous pouvez toujours avoir un balisage WebForms - idéal pour la compatibilité et la mise à niveau incrémentielle ;
• possibilité d'utiliser les guillemets "" et '' à l'intérieur d'une même pièce (extrêmement utile).

J'aime mieux la syntaxe Spark pour les boucles/ifs - mélanger les accolades HTML <> et C# {} n'est pas très joli - mais c'est une opinion purement personnelle.

Il y a aussi des fonctionnalités très prometteuses dans Razor, par exemple les modèles en ligne. Étant donné que le créateur de Spark a été engagé par Microsoft, je pense qu'il y a un espoir que Razor soit un moteur de vues bien écrit, très utile et bien supporté. Bien sûr, je ne vais pas réécrire des centaines de mes vues Spark avec Razor (bien que j'aie réécrit des dizaines de mes vues WebForms avec Spark). Mais je vais certainement jeter un coup d'œil sérieux à Razor - je ne l'ai découvert que grâce à vos questions, merci - et ce que je vois maintenant semble prometteur. Il ne rivalise pas avec WebForms, bien sûr (tout moteur de vue est meilleur que WebForms), mais il semble être un bon choix pour un nouveau projet ASP.NET MVC, si vous n'avez pas encore trop investi dans un autre moteur de vue.

Answer 3

Pour moi, il y a trois raisons impérieuses :

1. Compilation - Les vues Razor peuvent être compilées dans une DLL. Nous obtenons enfin une véritable possibilité de réutilisation dans les projets Web .NET. Je peux avoir un objet d'entreprise qui sait comment s'afficher sans avoir ce code flottant sous forme de fichiers .ascx dans une partie du projet Web.

2. Testabilité - comme il est compilé dans une classe, je peux écrire un test unitaire et lui lancer des instances d'objets fictifs pour voir si le HTML est correct.

3. IntelliSense et le Syntaxe laconique sont agréables mais ne sont pas les plus importantes.

Answer 4

Évidemment, je ne l'ai pas encore évalué en pratique, mais le fait qu'il soit plus rapide que le moteur ASPX est la caractéristique la plus convaincante pour inciter à changer. J'espère seulement qu'il s'auto-formatera aussi plus joliment. Le fait qu'il sera supporté par intellisense et livré avec MVC en fait un choix naturel pour le démarrage de nouveaux projets. Je vais lui donner une chance sur un petit projet avant de passer à l'action. En lisant l'article, je n'ai rien vu que je ne puisse pas faire avec lui, alors que je le fais actuellement avec le moteur ASPX.

Mise à jour : J'utilise Razor depuis plus d'un an maintenant et je ne reviendrai jamais au moteur ASPX. La syntaxe semble très naturelle et expressive.

Answer 5

Outre l'aspect plus propre, la flexibilité des sections de mise en page est très bonne, et les aides HTML déclaratives semblent très utiles. Jusqu'à présent, je ne vois pas d'inconvénient à l'utiliser, mais il faudra bien sûr l'essayer en pratique.