Razor/CSHTML - Quels sont les avantages par rapport à ce que nous avons ?

Question

Quelqu'un utilise-t-il la nouvelle fonctionnalité des pages CSHTML et préfère-t-il la syntaxe de ce nouveau moteur de vue au moteur de vue par défaut d'ASP.NET MVC ou aux formulaires web, et si oui, pourquoi ? Qu'est-ce qui, dans CSHTML, vous donne un avantage par rapport à MVC ou aux formulaires web, ou vice versa ?

Je suis juste curieux d'entendre le point de vue des gens à ce sujet.

Answer 1

L'un des avantages est que les vues Razor peuvent être rendues à l'intérieur des tests unitaires, ce qui n'était pas facilement possible avec l'ancien moteur de rendu ASP.Net.

De Annonce de ScottGu Cet aspect est l'un des objectifs de la conception :

Testable à l'unité : La nouvelle implémentation du moteur de vue permettra de tester les vues à l'unité (sans nécessiter de contrôleur ou de serveur web, et peut être hébergée dans n'importe quel projet de test à l'unité - aucun domaine d'application spécial n'est requis).

Answer 2

L'avis d'un ex-développeur Microsoft

J'ai travaillé au sein d'une équipe de base pour le site web MSDN. Aujourd'hui, j'utilise c# razor pour des sites de commerce électronique avec mon équipe de programmation et nous nous concentrons fortement sur le front-end jQuery avec des pages back-end c# razor et une base de données à mémoire LINQ-Entity de sorte que les pages ont des temps de réponse de 1 à 2 millisecondes même avec des boucles for imbriquées avec des requêtes et pas de mise en cache de la page. Nous n'utilisons pas de MVC, mais simplement ASP.NET avec des pages razor mappées avec le module URL Rewrite pour IIS 7, sans pages ASPX, ViewState ou programmation d'événements côté serveur. Il n'y a pas les couches supplémentaires (inutiles) que MVC met en place dans les constructions de code pour la regex contestée. Pour nous, moins c'est plus. C'est tout ce qu'il y a de plus simple et de plus efficace, mais je donne un coup de pouce à MVC pour sa testabilité, mais c'est tout.

Les pages Razor n'ont pas de cycle de vie événementiel comme les pages ASPX. Il s'agit simplement d'un rendu d'une page demandée. C# est un langage formidable et Razor s'écarte gentiment de son chemin pour lui permettre de faire son travail. Le typage anonyme avec generics et linq rend la vie si facile avec le C# et les pages Razor. L'utilisation des pages Razor vous aidera à penser et à coder plus légèrement.

L'un des inconvénients de Razor et de MVC est qu'il n'y a pas de persistance de type ViewState. J'avais besoin d'implémenter une solution pour cela et j'ai fini par écrire un plugin jQuery pour cela ici -> http://www.jasonsebring.com/dumbFormState qui est un plugin HTML 5 supportant le stockage hors ligne pour l'état des formulaires et qui fonctionne dans tous les principaux navigateurs. Il ne s'agit pour l'instant que de l'état des formulaires, mais vous pouvez utiliser window.sessionStorage ou window.localStorage très simplement pour stocker n'importe quel type d'état à travers les postbacks ou même les requêtes de page, j'ai juste pris la peine de le sauvegarder automatiquement et de le nommer en fonction de l'URL et de l'index du formulaire pour que vous n'ayez pas à y penser.

Answer 3

1. Tout est encodé par défaut !!! C'est énorme.

2. Les aides déclaratives peuvent être compilées, de sorte qu'il n'est pas nécessaire de faire quoi que ce soit de spécial pour les partager. Je pense qu'ils remplaceront les contrôles .ascx dans une certaine mesure. Pour utiliser un contrôle .ascx dans un autre projet, il faut passer par un certain nombre d'étapes.

3. Il est possible d'exiger une section, ce qui est appréciable.

Answer 4

Le principal avantage est que le code est plus succinct. L'éditeur VS disposera également d'un support IntelliSense que certains autres moteurs de visualisation n'ont pas.

Les aides HTML déclaratives ont également l'air plutôt cool, car le fait de faire des aides HTML dans le code C# me rappelle les contrôles personnalisés dans ASP.NET. Je pense qu'ils se sont inspirés des partials, mais avec le code en ligne.

Il y a donc des avantages certains par rapport à l'asp.net view engine.

Contrairement à un moteur de visualisation comme spark :

Spark est encore plus succinct, vous pouvez garder les ifs et les boucles à l'intérieur d'une balise html elle-même. Le balisage me semble toujours plus naturel.

Vous pouvez coder les partiels exactement comme vous le feriez pour une aide déclarative, vous n'avez qu'à passer les variables au partiel et vous obtenez la même chose. Cela existe dans spark depuis un certain temps.