ASP.NET MVC 3 – Modèle partiel vs modèle vs éditeur

Donc, le titre devrait parler de lui-même.

Pour créer des composants réutilisables dans ASP.NET MVC, nous avons 3 options (d’autres que je n’ai pas mentionnées):

Vue partielle:

@Html.Partial(Model.Foo, "SomePartial") 

Modèle de l’éditeur personnalisé:

 @Html.EditorFor(model => model.Foo) 

Modèle d’affichage personnalisé:

 @Html.DisplayFor(model => model.Foo) 

En termes de View / HTML, les trois implémentations sont identiques:

 @model WebApplications.Models.FooObject  

Alors, ma question est: quand / comment décidez-vous lequel des trois utiliser?

Ce que je recherche vraiment, c’est une liste de questions à vous poser avant d’en créer une, pour laquelle les réponses peuvent être utilisées pour décider du modèle à utiliser.

Voici les 2 choses que j’ai trouvé mieux avec EditorFor / DisplayFor:

  1. Ils respectent les hiérarchies de modèles lors du rendu des aides HTML (par exemple, si vous avez un object “Bar” sur votre modèle “Foo”, les éléments HTML pour “Bar” seront affichés avec “Foo.Bar.ElementName”, alors qu’un partiel aura ” ElementName “).

  2. Plus robuste, par exemple si vous avez une List de quelque chose dans votre ViewModel, vous pouvez utiliser @Html.DisplayFor(model => model.CollectionOfFoo) , et MVC est assez intelligent pour voir sa collection et rendre l’affichage unique pour chaque élément (par opposition à un partiel, ce qui nécessiterait une boucle explicite).

J’ai également entendu que DisplayFor restitue un modèle “en lecture seule”, mais je ne comprends pas cela – est-ce que je ne peux pas y envoyer un formulaire?

Quelqu’un peut-il me dire d’autres raisons? Y a-t-il une liste / un article quelque part comparant les trois?

EditorFor vs DisplayFor est simple. La sémantique des méthodes consiste à générer des vues edit / insert et display / read only (respectivement). Utilisez DisplayFor lors de l’affichage des données (c’est-à-dire lorsque vous générez des div et des spans contenant les valeurs du modèle). Utilisez EditorFor lors de l’édition / insertion de données (c’est-à-dire lorsque vous générez des tags d’entrée dans un formulaire).

Les méthodes ci-dessus sont centrées sur le modèle. Cela signifie qu’ils prendront en compte les métadonnées du modèle (par exemple, vous pouvez annoter votre classe de modèle avec [UIHintAtsortingbute] ou [DisplayAtsortingbute] et cela [UIHintAtsortingbute] sur le modèle choisi pour générer l’interface utilisateur du modèle. Ils sont également utilisés pour modèles de données (c.-à-d. modèles représentant des lignes dans une firebase database, etc.)

Par contre, Partial est centré sur la vue en ce sens que vous êtes principalement concerné par le choix de la vue partielle correcte. La vue n’a pas nécessairement besoin d’un modèle pour fonctionner correctement. Il ne peut s’agir que d’un jeu de balisage commun réutilisé sur l’ensemble du site. Bien entendu, il arrive souvent que vous souhaitiez affecter le comportement de ce partiel, auquel cas vous souhaiterez peut-être utiliser un modèle de vue approprié.

Vous n’avez pas demandé à propos de @Html.Action qui mérite également une mention ici. Vous pouvez le considérer comme une version plus puissante de Partial dans la mesure où il exécute une action enfant de contrôleur et affiche ensuite une vue (qui est généralement une vue partielle). Ceci est important car l’action enfant peut exécuter une logique métier supplémentaire n’appartenant pas à une vue partielle. Par exemple, il pourrait s’agir d’un composant de panier d’achat. La raison de l’utiliser est d’éviter d’exécuter le travail lié au panier dans chaque contrôleur de votre application.

En fin de compte, le choix dépend de ce que vous modélisez dans votre application. Rappelez-vous également que vous pouvez mélanger et assortir. Par exemple, vous pouvez avoir une vue partielle qui appelle l’assistant EditorFor . Cela dépend vraiment de la nature de votre application et de la manière de la prendre en compte pour encourager une réutilisation maximale du code tout en évitant les répétitions.

Vous pouvez certainement personnaliser DisplayFor pour afficher un formulaire modifiable. Mais la convention est que DisplayFor soit en readonly et EditorFor pour l’édition. S’en tenir à la convention garantira que peu importe ce que vous passerez dans DisplayFor , cela fera le même type de chose.

Juste pour donner ma valeur de 2c, notre projet utilise une vue partielle avec plusieurs tabs jQuery, et chaque onglet rend ses champs avec sa propre vue partielle. Cela a bien fonctionné jusqu’à ce que nous ajoutions une fonctionnalité permettant à certains des tabs de partager des champs communs. Notre première approche consistait à créer une autre vue partielle avec ces champs communs, mais cela devenait très maladroit lorsque nous utilisions EditorFor et DropDownListFor pour rendre des champs et des listes déroulantes. Pour obtenir les identifiants et les noms uniques, nous avons dû rendre les champs avec un préfixe en fonction de la vue partielle parente qui le rendait:

   

Cela a été plutôt moche et nous avons donc décidé d’utiliser plutôt des modèles d’éditeur, qui étaient beaucoup plus propres. Nous avons ajouté un nouveau modèle de vue avec les champs communs, ajouté un modèle d’éditeur correspondant et rendu les champs à l’aide du modèle d’éditeur à partir de différentes vues parentes. Le modèle d’éditeur affiche correctement les identifiants et les noms.

Donc, en résumé, une raison impérieuse d’utiliser des modèles d’éditeur était la nécessité de rendre certains champs communs dans plusieurs tabs. Les vues partielles ne sont pas conçues pour cela, mais les modèles d’éditeur gèrent parfaitement le scénario.

Utilisez l’approche de vue _partial si:

  1. Afficher la logique centralisée
  2. Que ne doit-on garder que le HTML associé à la vue _partial dans cette vue? Dans la méthode du modèle, vous devrez conserver du code HTML en dehors de la vue Modèle, comme “En-tête principal ou toute bordure / parameters externes”.
  3. Vous voulez rendre une vue partielle avec la logique (du contrôleur) en utilisant URL.Action("action","controller") .

Raisons d’utiliser le modèle:

  1. Vous voulez supprimer ForEach(Iterator) . Le modèle est suffisamment bien pour identifier le modèle en tant que type de liste. Il le fera automatiquement.
  2. Logique centrée sur le modèle. Si plusieurs vues sont trouvées dans le même affichage pour le dossier Template, le rendu dépendra du modèle passé.

Une autre différence qui n’a pas été mentionnée jusqu’à présent est qu’une vue partielle n’ajoute pas de préfixes de modèle alors qu’un modèle ne le fait pas