ASP.NET MVC 3 - partielle contre modèle d’affichage contre l’éditeur de Template

Question

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

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

Vue Partielle:

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

La Coutume De L'Éditeur De Template:

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

Affichage Personnalisé De Modèle:

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

En ce qui concerne les Afficher/HTML, tous les trois implémentations sont identiques:

@model WebApplications.Models.FooObject

<!-- Bunch of HTML -->

Donc, ma question est - quand/comment voulez-vous décider lequel des trois?

Ce que je suis vraiment à la recherche d'une liste de questions à vous poser avant de créer, pour lequel les réponses peuvent être utilisés pour décider sur le modèle à utiliser.

Voici les 2 choses que j'ai trouvé de mieux avec EditorFor/méthode displayfor:

1. Ils respectent le modèle de hiérarchies lors du rendu HTML helpers (e.g si vous avez un "Bar" dans l'objet de votre "Foo" du modèle, les éléments HTML pour la "Barre" sera affiché avec "Toto.Bar.ElementName", tandis qu'un partiel aura "ElementName").

2. Plus robuste, e.g si vous avez eu une List<T> de quelque chose dans votre ViewModel, vous pouvez utiliser @Html.DisplayFor(model => model.CollectionOfFoo), et MVC est assez intelligent pour voir que c'est une collecte et le rendu de l'écran d'affichage unique pour chaque élément (par opposition à une Partielle, qui aurait besoin d'une explicite pour la boucle).

J'ai aussi entendu méthode displayfor rend une "lecture seule" modèle, mais je ne comprends pas - je n'ai pas pu jeter un formulaire de là-bas?

Quelqu'un peut me dire d'autres raisons? S'il existe une liste/article quelque part en comparant les trois?

Answer 1

EditorFor vs DisplayFor est simple. La sémantique des méthodes consiste à générer edition/insérer et de les afficher/lire uniquement des vues (respectivement). Utiliser DisplayFor lors de l'affichage des données (c'est à dire lorsque vous générez des divs et s'étend sur qui contiennent les valeurs de modèle). Utiliser EditorFor lors de la modification/insertion de données (c'est à dire lors de la génération d'entrée balises à l'intérieur d'un formulaire).

Les méthodes ci-dessus sont centrée sur le modèle. Cela signifie qu'ils vont prendre le modèle de métadonnées en compte (par exemple, vous pouvez annoter votre modèle de classe avec [UIHintAttribute] ou [DisplayAttribute] , et cela peut influencer le modèle choisit-on pour générer l'INTERFACE utilisateur pour le modèle. Ils sont aussi 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 vue centrée sur les qui vous concernent principalement le choix de la bonne vue partielle. La vue n'a pas nécessairement besoin d'un modèle pour fonctionner correctement. Il peut juste avoir un ensemble commun de balises qui est réutilisé sur tout le site. Bien sûr, la plupart du temps vous voulez affecter le comportement de cette partielle dans ce cas, vous pourriez passer dans un modèle de vue.

Vous n'avez pas posé @Html.Action qui mérite également une mention ici. Vous pourriez penser que c'est un version plus puissante Partial en ce qu'il exécute un contrôleur de l'action enfant, puis rend un avis (qui est généralement une vue partielle). Ceci est important parce que l'enfant d'action peut exécuter d'autres entreprises de la logique qui n'appartient pas à une vision partielle. Par exemple, il pourrait s'agir d'un panier d'achat d'un composant. La raison pour l'utiliser, il est à éviter d'effectuer le panier-travaux connexes dans chaque contrôleur dans votre application.

Finalement, le choix dépend de qu'est-ce que vous êtes de la modélisation dans votre application. Rappelez-vous aussi que vous pouvez mélanger et assortir. Par exemple, vous pourriez avoir une vue partielle qui appelle l' EditorFor helper. Cela dépend vraiment de ce que votre demande est et comment le facteur d'encourager au maximum la réutilisation du code, tout en évitant la répétition.

Answer 2

Vous pourriez certainement personnaliser pour afficher un formulaire modifiable. Mais la convention est pour d’être et d’être pour l’édition. S’en tenir à la convention fera en sorte que peu importe ce que vous passer en `` , il va faire le même type de chose.

Answer 3

Juste pour donner mon 2c valeur, notre projet est à l'aide d'une vue partielle avec plusieurs onglets jQuery, et chaque onglet rendu ses champs avec sa propre vision partielle. Cela fonctionnait bien jusqu'à ce que nous avons ajouté une fonctionnalité pour permettre à certains des onglets partagé des champs communs. Notre première approche a été de créer une autre vue partielle avec ces champs, mais c'est très maladroit lors de l'utilisation de EditorFor et DropDownListFor rendre des champs et des menus déroulants. Pour obtenir les identifiants et les noms uniques nous avons eu de rendre les champs avec un préfixe en fonction du parent vue partielle qui a été rendu:

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

C'est assez laid, donc nous avons décidé d'utiliser l'Éditeur de Modèles au lieu, qui a beaucoup plus propre. Nous avons ajouté un nouveau Modèle de Vue avec la commune de champs, ajout d'une correspondance de l'Éditeur de Modèle, et rendu le champs à l'aide de l'Éditeur de Template de parents différents points de vue. L'Éditeur de Modèle correctement rend les identifiants et les noms.

Donc, en bref, une raison convaincante pour nous d'utiliser l'Éditeur de Modèles a été la nécessité de rendre certains champs communs dans plusieurs onglets. Vues partielles ne sont pas conçus pour cela, mais l'Éditeur de Modèles de gérer le scénario parfaitement.