ASP.NET MVC 3 - Modèle d'affichage partiel vs

StackOverflow https://stackoverflow.com/questions/5037580

Question

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

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

Vue partielle:

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

Modèle d'éditeur personnalisé:

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

Modèle d'affichage personnalisé:

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

En termes de vue réelle / HTML, les trois implémentations sont identiques:

@model WebApplications.Models.FooObject

<!-- Bunch of HTML -->

Donc, 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ées mieux avec EditorFor / DisplayFor:

  1. Ils respectent les hiérarchies du modèle lors de la rendu des aides HTML (par exemple, si vous avez un objet "bar" sur votre modèle "foo", les éléments HTML pour "bar" seront rendus avec "foo.bar.elementName", tandis qu'un partiel sera " ElementName ").

  2. Plus robuste, par exemple si vous aviez un List<T> de quelque chose dans votre mode View, vous pouvez utiliser @Html.DisplayFor(model => model.CollectionOfFoo), et MVC est assez intelligent pour voir qu'il s'agit d'une collection et de rendre l'affichage unique pour chaque élément (par opposition à un partiel, qui nécessiterait une boucle explicite).

J'ai également entendu dire que Display pour rendre un modèle "en lecture seule", mais je ne comprends pas cela - je ne pourrais pas jeter un formulaire là-bas?

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

Était-ce utile?

La solution

EditorFor contre DisplayFor est simple. La sémantique des méthodes consiste à générer des vues d'édition / insérer et d'afficher / lire uniquement (respectivement). Utilisation DisplayFor Lors de l'affichage des données (c'est-à-dire lorsque vous gérez des div et des portées qui contiennent les valeurs du modèle). Utilisation EditorFor Lorsque vous modifiez / insérant des données (c'est-à-dire lorsque vous générez des balises d'entrée dans un formulaire).

Les méthodes ci-dessus sont centrées sur le modèle. Cela signifie qu'ils prendront compte des métadonnées du modèle (par exemple, vous pourriez annoter votre cours de modèle avec [UIHintAttribute] ou [DisplayAttribute] Et cela influencerait le modèle qui est choisi pour générer l'interface utilisateur pour le modèle. Ils sont également généralement utilisés pour les modèles de données (c'est-à-dire des modèles qui représentent les lignes dans une base de données, etc.)

D'autre part Partial est centré sur la vue en ce que vous êtes principalement soucieux de choisir la vue partielle correcte. La vue n'a pas nécessairement besoin d'un modèle pour fonctionner correctement. Il peut simplement avoir un ensemble commun de balisage qui est réutilisé sur tout le site. Bien sûr, souvent, vous voulez affecter le comportement de ce partiel, auquel cas vous voudrez peut-être passer dans un modèle de vue approprié.

Vous n'avez pas posé de questions sur @Html.Action qui mérite également une mention ici. Vous pourriez le considérer comme une version plus puissante de Partial en ce qu'il exécute une action d'enfant de contrôleur, puis rend une vue (qui est généralement une vue partielle). Ceci est important car l'action de l'enfant peut exécuter une logique commerciale supplémentaire qui n'appartient pas à une vue partielle. Par exemple, il pourrait représenter un composant de panier d'achat. La raison de l'utiliser est d'éviter d'effectuer 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. N'oubliez pas non plus que vous pouvez mélanger et assortir. Par exemple, vous pourriez avoir une vue partielle qui appelle le EditorFor assistant. Cela dépend vraiment de votre application et de la façon de le prendre en compte pour encourager la réutilisation maximale du code tout en évitant la répétition.

Autres conseils

Vous certainement pourrait Personnaliser DisplayFor Pour afficher une forme modifiable. Mais la convention est pour DisplayFor être readonly et EditorFor être pour l'édition. S'en tenir à la convention garantira que peu importe ce que vous passez DisplayFor, il fera le même type de chose.

Juste pour donner mon 2C, notre projet utilise une vue partielle avec plusieurs onglets jQuery, et chaque onglet rendant ses champs avec sa propre vue partielle. Cela a bien fonctionné jusqu'à ce que nous ajoutions une fonctionnalité par laquelle certains des onglets partageaient certains champs communs. Notre première approche a été de créer une autre vue partielle avec ces champs communs, mais cela est devenu très maladroit lors de l'utilisation de l'éditeur pour et dropdownlistfor pour rendre des champs et des couverts. Afin d'obtenir des identifiants et des noms uniques, nous avons dû rendre les champs avec un préfixe en fonction de la vue partielle des parents qui le rendait:

    <div id="div-@(idPrefix)2" class="toHide-@(idPrefix)" style="display:none">
    <fieldset>
        <label for="@(idPrefix).Frequency">Frequency<span style="color: #660000;"> *</span></label>

        <input name="@(idPrefix).Frequency"
               id="@(idPrefix)_Frequency"
               style="width: 50%;"
               type="text"
               value="@(defaultTimePoint.Frequency)"
               data-bind="value: viewState.@(viewStatePrefix).RecurringTimepoints.Frequency"
               data-val="true"
               data-val-required="The Frequency field is required."
               data-val-number="The field Frequency must be a number."
               data-val-range-min="1"
               data-val-range-max="24"
               data-val-range="The field Frequency must be between 1 and 24."
               data-val-ignore="true"/>

        @Html.ValidationMessage(idPrefix + ".Frequency")

        ... etc

    </fieldset>
</div>

Cela est devenu assez moche, nous avons donc décidé d'utiliser des modèles d'éditeur à la place, ce qui a fonctionné beaucoup plus propre. 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 parentales. Le modèle d'éditeur rend correctement les ID et les noms.

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

Utilisation _partial Afficher l'approche si:

  1. Afficher la logique centrée
  2. Que garder tout _partial Afficher HTML associé dans cette vue uniquement. Dans la méthode du modèle, vous devrez garder un HTML à l'extérieur de la vue de modèle comme "En-tête principal ou toute bordure / paramètres extérieurs.
  3. Souhaite rendre une vue partielle avec logique (du contrôleur) en utilisant URL.Action("action","controller").

Raisons d'utiliser le modèle:

  1. Veux supprimer ForEach(Iterator). Le modèle est suffisant pour identifier le modèle comme un type de liste. Il le fera automatiquement.
  2. Logique centrée sur le modèle. Si plusieurs vues se trouvent dans le même dossier DisplayFor pour le modèle, le rendu dépendra du modèle passé.

Une autre différence qui n'a pas été mentionnée jusqu'à présent est qu'un PartialView n'ajoute pas les préfixes de modèle pendant qu'un modèle faitIci est le problème

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top