MVC 4 Anotaciones de datos "Pantalla" Atributo

Estoy comenzando con MVC 4 (motor Razor view). (Creo que esto también se puede aplicar a MVC 3 y anteriores). Me pregunto si hay algún beneficio al usar la anotación de datos DisplayAttribute dentro de una vista, en lugar de simplemente escribir una cadena directamente en el HTML. Por ejemplo, si tuviera el siguiente modelo:MVC 4 Anotaciones de datos "Pantalla" Atributo

public class Thing 
{ 
    public string WildAndCrazyProperty { get; set; } 
}

... ¿habría ningún beneficio en la anotación de la propiedad como:

[Display(Name = "Wild and Crazy")] 
    public string WildAndCrazyProperty { get; set; }

... y habiendo sido mi marcado:

<html> 
    <body> 
     <div>@Html.DisplayNameFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
     <div>@Html.DisplayFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
    </body> 
</html>

... frente al no tener la anotación, y haciendo:

<html> 
    <body> 
     <div>Wild and Crazy</div> 
     <div>@Html.DisplayFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
    </body> 
</html>

La razón por la que no he mencionado Html.LabelFor en este caso se debe a que los datos de la propiedad se muestran como estáticos (es decir, texto no editable) en la página. Los datos nunca serán editables en esta página, por lo que no es necesario que use Html.TextBoxFor dentro del segundo div > y luego use Html.LabelFor para asociar correctamente una etiqueta con ese cuadro de texto.

Fuente

2012-10-04 Kenneth K.

Si dos vistas diferentes comparten el mismo modelo (por ejemplo, tal vez una es para salida móvil y una es regular), podría ser bueno tener la cadena residir en un solo lugar: como metadatos en el modelo de vista.

Además, si tenía una versión heredada del modelo que requería una pantalla diferente, podría ser útil. Por ejemplo:

public class BaseViewModel 
{ 
    [Display(Name = "Basic Name")] 
    public virtual string Name { get; set; } 
} 

public class OtherViewModel : BaseViewModel 
{ 
    [Display(Name = "Customized Inherited Name")] 
    public override string Name { get; set; } 
}

voy a admitir que este ejemplo es bastante artificial ...

Esos son los mejores argumentos a favor del uso del atributo que pueda ocurrir. Mi opinión personal es que, en su mayor parte, ese tipo de cosas es mejor dejarlas en el marcado.

Fuente

2012-10-04 21:00:24 eouw0o83hf

Y esa es la forma en que me inclino. Parece que desearía algo que realmente sea más una cosa de tipo pantalla en la parte del código que hace la visualización real. Tener que recompilar el proyecto solo para cambiar un encabezado o dos parece innecesario. –

Estoy completamente de acuerdo en el punto de recopilación. Siento que incluso si tuviera que usar el modelo en múltiples vistas, las ventajas de poner esa información en un atributo no superan las desventajas. – eouw0o83hf

Así que realmente me gusta el concepto detrás de esta respuesta, sin embargo, no funciona para mí. Mi clase heredera no anula el atributo 'Display' de la clase base. ¿Alguna razón por qué? – Kehlan

Uno de los beneficios es que puede usarlo en múltiples vistas y tener un texto de etiqueta consistente. También es utilizado por los andamios asp.net MVC para generar el texto etiquetas y hace que sea más fácil para generar texto significativo

[Display(Name = "Wild and Crazy")] 
public string WildAndCrazyProperty { get; set; }

"salvaje y loco" aparece consistentemente donde se utiliza la propiedad en su aplicación.

A veces esto no es flexible ya que es posible que desee cambiar el texto en alguna vista. En ese caso, tendrá que usar marcado personalizado como en su segundo ejemplo

Fuente

2012-10-04 21:01:07 codingbiz

En este caso, solo tengo una vista, por lo que tal vez es por eso que no pude percibir un beneficio. A pesar de este beneficio, parece que uno podría tener una mayor cantidad de vistas reutilizando esta misma propiedad antes de que la consecuencia de la recompilación sea superada por el beneficio. –

Además de las otras respuestas, hay un gran beneficio al usar el DisplayAttribute cuando desea localizar los campos. Puede buscar el nombre en una base de datos de localización usando DisplayAttribute y usará la traducción que desee.

Además, puede dejar que MVC genere las plantillas para usted utilizando Html.EditorForModel() y generará la etiqueta correcta para usted.

En última instancia, es su decisión. Pero el MVC está muy "centrado en el modelo", por lo que los atributos de datos se aplican a los modelos, de modo que los metadatos existen en un solo lugar. No es que sea una gran cantidad de tipeo extra lo que tienes que hacer.

Fuente

2012-10-04 21:05:56

En mi caso actual, la aplicación es solo una interfaz de prueba para un servicio WebAPI. Ninguna localización es necesaria; pero puedo ver el beneficio de tal comportamiento. –

@KennethK. - hay muchas cosas que pueden no beneficiarte ahora, pero es posible que desees haberlo hecho más tarde. Usar una arquitectura de 3 niveles puede que no te beneficie ahora, pero luego ... estarás golpeando la cabeza. El punto es, úsalo o no ... es tu elección, pero trata de no insinuar que es inútil. –

Si me pareció que implicaba que la técnica era inútil, ciertamente no tenía la intención de hacerlo. Como mencioné, la aplicación es simplemente una fachada para un servicio web. No hay posibilidad de que la aplicación se use fuera de esta capacidad. Dado que la aplicación consiste en exactamente una vista, no pude ver el beneficio. Ahora bien, si estuviera diseñando una aplicación pública con una audiencia global, sí, lo que describes tiene mucho sentido. Es el tamaño de esta aplicación particular que no dejó en claro por qué el atributo sería útil. –

MVC 4 Anotaciones de datos "Pantalla" Atributo

Respuesta

Cuestiones relacionadas