asp.net-mvc - places - html editorformodel

ASP.NET MVC 3-Plantilla de visualización parcial vs Plantilla de editor vs

Question

Por lo tanto, el título debe hablar por sí mismo.

Para crear componentes reutilizables en ASP.NET MVC, tenemos 3 opciones (podrían ser otras que no he mencionado):

Vista parcial:

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

Plantilla de editor personalizado:

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

Plantilla de visualización personalizada:

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

En términos de la vista real / HTML, las tres implementaciones son idénticas:

@model WebApplications.Models.FooObject

<!-- Bunch of HTML -->

Entonces, mi pregunta es: ¿cuándo / cómo decides cuál de los tres usar?

Lo que realmente estoy buscando es una lista de preguntas que debe hacerse antes de crear una, para la cual las respuestas se pueden usar para decidir qué plantilla usar.

Aquí están las 2 cosas que he encontrado mejor con EditorFor / DisplayFor:

1. Respetan las jerarquías de modelo cuando representan ayudantes HTML (por ejemplo, si tiene un objeto "Barra" en su modelo "Foo", los elementos HTML para "Barra" se representarán con "Foo.Bar.ElementName", mientras que un parcial tendrá " ElementName ").

2. Más robusto, por ejemplo, si tenía una List<T> de algo en su ViewModel, podría usar @Html.DisplayFor(model => model.CollectionOfFoo) , y MVC es lo suficientemente inteligente como para ver que es una colección y mostrar la única pantalla. para cada elemento (a diferencia de un parcial, que requeriría un bucle explícito para).

También escuché que DisplayFor muestra una plantilla de "solo lectura", pero no entiendo eso. ¿No puedo lanzar un formulario allí?

¿Puede alguien decirme algunas otras razones? ¿Hay una lista / artículo en algún lugar comparando los tres?

Answer 1

Otra diferencia que no se ha mencionado hasta ahora es que una vista parcial no agrega prefijos de modelo mientras que una plantilla sí. Here es el problema.

Answer 2

Sin duda, puede personalizar DisplayFor para mostrar un formulario editable. Pero la convención es que DisplayFor sea ​​de readonly y EditorFor que sea para edición. Cumplir con la convención asegurará que no importa lo que pase en DisplayFor , hará el mismo tipo de cosas.

Answer 3

Solo para dar valor a mi 2c, nuestro proyecto utiliza una vista parcial con varias pestañas jQuery, y cada pestaña representa sus campos con su propia vista parcial. Esto funcionó bien hasta que agregamos una característica por la cual algunas de las pestañas compartían algunos campos comunes. Nuestro primer acercamiento a esto fue crear otra vista parcial con estos campos comunes, pero esto se volvió muy torpe al usar EditorFor y DropDownListFor para renderizar campos y desplegables. Para obtener los identificadores y los nombres únicos, tuvimos que renderizar los campos con un prefijo, dependiendo de la vista parcial primaria que lo representaba:

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

Esto se puso bastante feo, así que decidimos usar Plantillas de Editor, lo que resultó mucho más limpio. Agregamos un nuevo modelo de vista con los campos comunes, agregamos una plantilla de editor coincidente y representamos los campos usando la plantilla de editor desde diferentes vistas principales. La plantilla del editor representa correctamente los identificadores y los nombres.

Entonces, en resumen, una razón convincente para que usemos las plantillas del editor fue la necesidad de representar algunos campos comunes en varias pestañas. Las vistas parciales no están diseñadas para esto, pero las Plantillas del Editor manejan el escenario perfectamente.

Answer 4

Utilice el _partial vista _partial si:

1. Ver Centric Logic
2. Lo que debe mantener todo el HTML relacionado con la vista _partial en esta vista solamente. En el método de plantilla, tendrá que mantener algo de HTML fuera de la Vista de la plantilla como "Encabezado principal o cualquier borde / configuración exterior.
3. Desea renderizar una vista parcial con lógica (desde el controlador) usando URL.Action("action","controller") .

Razones para usar la Plantilla:

1. ¿Quieres eliminar ForEach(Iterator) . La plantilla es suficiente para identificar el modelo como un tipo de lista. Lo hará automáticamente.
2. Modelo de lógica céntrica. Si se encuentran varias vistas en la misma pantalla para la carpeta de plantillas, entonces la representación dependerá del modelo aprobado.

Answer 5

EditorFor vs DisplayFor es simple. La semántica de los métodos es generar vistas de edición / inserción y visualización / solo lectura (respectivamente). Use DisplayFor cuando muestre datos (es decir, cuando genere divs y spans que contengan los valores del modelo). Use EditorFor cuando EditorFor / inserte datos (es decir, cuando genere etiquetas de entrada dentro de un formulario).

Los métodos anteriores son centrados en el modelo. Esto significa que tomarán en cuenta los metadatos del modelo (por ejemplo, podría anotar su clase de modelo con [UIHintAttribute] o [DisplayAttribute] y esto influiría en qué plantilla se elige para generar la interfaz de usuario para el modelo. También se usan generalmente para modelos de datos (es decir, modelos que representan filas en una base de datos, etc.)

Por otra parte, Partial está centrado en la vista, ya que le preocupa más la elección de la vista parcial correcta. La vista no necesariamente necesita un modelo para funcionar correctamente. Simplemente puede tener un conjunto común de marcas que se reutiliza en todo el sitio. Por supuesto, muchas veces desea afectar el comportamiento de este parcial, en cuyo caso es posible que desee pasar un modelo de vista apropiado.

No preguntaste sobre @Html.Action que también merece una mención aquí. Podría pensar que es una versión más potente de Partial que ejecuta una acción secundaria del controlador y luego presenta una vista (que generalmente es una vista parcial). Esto es importante porque la acción secundaria puede ejecutar lógica de negocios adicional que no pertenece a una vista parcial. Por ejemplo, podría representar un componente del carrito de compras. La razón para usarlo es evitar realizar el trabajo relacionado con el carrito de compras en cada controlador de su aplicación.

En última instancia, la elección depende de qué es lo que está modelando en su aplicación. También recuerda que puedes mezclar y combinar. Por ejemplo, podría tener una vista parcial que llame al EditorFor helper. Realmente depende de lo que sea su aplicación y cómo factorizarla para fomentar la reutilización máxima del código y evitar la repetición.