¿Es generalmente una buena práctica tener ambos modelos de visualización y edición para una aplicación MVC? Es decir, no me gustaría que los atributos de validación en un modelo de vista ya que es básicamente de solo lectura.ASP.NET MVC - ViewModels For Edit
Puede tener una propiedad llamada ReadOnly (boolean) en su ViewModel. Según esa propiedad, se puede representar la vista apropiada.
Puede usar su modelo para fines de edición. Usted vincula atributos editables a la Vista y otros permanecen igual incluso si alguien fuera a falsificar entradas.
public ActionResult Update([Bind(Include=”First, Last”)]User user)
Esto asegura que acaba de obtener los campos con nombre Primero y Apellido.
Quizás no lo haya visto, pero no muestra entradas editables para atributos de modelos no editables.
Si sus vistas son vistas CRUD, tiene sentido usar el mismo modelo de vista. En la vista de solo lectura, los atributos de validación se ignorarían ya que no está ingresando un formulario. Una vez que se aleja de CRUD, tiene muchas más variaciones en cómo estructurar sus máquinas virtuales. Tengo algunas situaciones en las que un campo solo se puede configurar durante la inserción. En este caso, utilizo la misma máquina virtual para representar las pantallas de agregar, solo leer y actualizar (con DisplayFor frente a InputFor en la vista html), pero tengo diferentes modelos de entrada en mis métodos de acción Insertar y Actualizar.
Generalmente, creo un nuevo modelo de vista para cada vista. Encuentro que la reutilización en la práctica de ViewModels es muy baja y tratar de que sean súper genéricos no funciona bien y conduce a casos extraños.
Cuando comencé a crear ViewModels, creaba estos ViewModels realmente abstractos en los que intentaba aplicar un montón de lógica empresarial, pero luego me di cuenta de que en la mayoría de los casos los datos que intentaba mostrar en cada caso eran totalmente diferente y la reutilización no funcionaba. Así que empecé a dividir mis ViewModels en piezas muy pequeñas que se usan una vez. Hasta ahora esto ha funcionado bien.
La mayor parte de mi lógica comercial ahora intento mantenerme en el modelo en lugar del modelo de vista. En mi caso, mi modelo es un modelo de marco de entidad y pongo la lógica de negocios en clases parciales colgando de mis objetos DB.
Creo que está malinterpretando el propósito de separar la vista y el modelo en el patrón de control de vista modelo.
La vista consiste en definir cómo verá el usuario los datos, es decir, cómo será la página web.
El modelo define los datos que se utilizarán, es decir, el contenido que se mostrará en la vista.
Si decide que necesita dos páginas web diferentes para ver datos y editar datos, entonces cabría en el patrón MVC que estas dos páginas deberían tener modelos y vistas diferentes.
Pero generalmente estoy en contra de separar la visualización y edición de datos en dos páginas web. Con ajax hoy solo lo haría en una página web.
Habla de ViewModels, no Vistas y Modelos. – UpTheCreek
Y la diferencia sería? – eaglestorm