De acuerdo con este blog post "Los objetos ModelMetadata se construyen con datos tomados de atributos, principalmente de los espacios de nombres System.ComponentModel y System.ComponentModel.DataAnnotations".ASP.NET MVC ModelMetadata - ¿Violamos la separación de preocupaciones cuando ponemos atributos para describir la UI en el modelo?
Al poner atributos de ayuda de UI en Objetos de modelo (DisplayFormat o UIHint) ¿no estamos acoplando Modelo y Vista?
Creo que sí. Personalmente, mantengo mi modelo completamente agnóstico y escribo ViewModels, que representará mi modelo en mi View. A continuación, asigne todas las anotaciones a estos ViewModels.
Creo que la violación proviene del hecho de que esto limita su capacidad de reutilizar su modelo, ya que básicamente está definiendo el comportamiento de vista en su modelo.
Parece que esta es una solución. Si no tengo control sobre el objeto Modelo, puedo crear un objeto contenedor (ViewModel) que describa el comportamiento de UI. –
Exactamente, y es lo que considero más limpio y más ampliable. Al principio, la posibilidad de codificar tus ViewModels parece un trabajo extra, y lo es, pero vale la pena. Más aún si se tiene en cuenta que los modelos pueden ser diferentes a los de sus modelos comerciales. – AJC
+1 Hago exactamente lo mismo. Mi 'Views' no está acoplada al' model' y '' ViewModel'' para cada 'View' –
Creo que sí.
Creo clases de modelos de vista específica que representan el intercambio de información entre el navegador y el servidor. Si el estado del modelo es válido, copio los valores o llamo a los métodos de dominio con esos valores (para eso está la carpeta Modelos). Nunca pongo atributos específicos de MVC en las entidades de mi dominio.
Regla de oro, mantengo mis entidades en un ensamblaje separado, que no sabe nada de MVC.
Tenga cuidado con exponer entidades de dominio en sus métodos de acción MVC ... la carpeta de modelo podría hacer una mala broma: D Si, por ejemplo, tiene una clase "Cuenta", con una propiedad "IsAdmin" y expone esta entidad en un formulario de registro, el usuario podría intentar pasar un parámetro arbitrario "IsAdmin = true" en la cadena GET o en la carga POST, y la carpeta de modelo MVC establecerá esa propiedad en su modelo ... y su código probablemente guarde esa información en la base de datos.
Por lo tanto, creo que es muy importante mantener la atención en los modelos de visualización.
Sé que con todas estas cosas "dinámicas" como ViewBag y que sus propias entidades LINQ sean parámetros en los métodos de acción todo se vuelve muy fácil de hacer ... pero no debemos pasar por alto la seguridad y reforzar la seguridad debemos asegurarnos de que solo la información que queremos pueda llegar a nuestro dominio.
Saludos.
Eso depende en gran medida de cómo se defina el "acoplamiento". Ya ha "acoplado" su Vista a su modelo en cierto sentido: su Vista usa las mismas propiedades que su Modelo define. El problema no es con el "acoplamiento" sino con "qué" y "cómo". El Modelo describe qué (debe mostrarse), depende de la Vista definir el Cómo (para hacerlo). Si desea seguir estrictamente este principio, debe descartar las sugerencias de UI.
Si quiere ser más práctico, a veces estos atributos pueden simplificar sus Vistas (que a menudo se vuelven demasiado complicadas). Eso depende de ti.
Si desea que su modelo sea reutilizable (lo que en la mayoría de los casos no es una buena idea, pero no nos volvamos dogmáticos), asegúrese de usar solo atributos que sean consistentes en toda la aplicación. Por ejemplo, si visualiza todos los números de punto flotante de la misma manera, tiene sentido colocar el atributo DisplayFormat en el modelo, en lugar de escribirlo una y otra vez en sus Vistas, contaminándolas con los detalles aburridos.
Tiendo a poner la estructura general en mi vista principal y delegar los detalles a los parciales, el atributo UIHint me ayuda mucho.Llámalo acoplamiento, pero el beneficio es simplemente enorme.
Es por eso que estos "modelos" se suelen denominar modelos de vista. – dotjoe