ASP.net MVC – ¿Un ViewModel por vista o por acción?

¿Es mejor tener un solo ViewModel por vista o uno por acción de controlador?

Ejemplo:

public ProjectController : Controller { public ActionResult Edit(int id) { var project = ...; return View(new ProjectEditViewModel(project)); } [HttpPost] public ActionResult Edit(ProjectEditViewModel model) { } **OR** [HttpPost] public ActionResult Edit(Project model) { } [HttpPost] public ActionResult Edit(ProjectEditPostViewModel model) { } } 

Aquí están las tres opciones, ¿cuál es la mejor?

  1. Usar el mismo ViewModel para mis acciones POST / GET.
  2. Usar un ViewModel para mi acción GET y mi modelo de dominio para mi acción POST.
  3. Utilice un ViewModel diferente para GET y un ViewModel diferente para POST.

Usar un modelo de vista diferente para las acciones GET y POST es el mejor y más flexible diseño. Pero el uso del mismo modelo de vista para las acciones GET y POST también funciona en el 90% de los casos y es un buen diseño. Por lo tanto, si usar el mismo modelo de vista funciona en su escenario, no dude en reutilizarlo de esta manera.

En el caso de que se utilicen diferentes modelos de vista para las acciones GET y POST, todavía hay alguna relación entre esas clases: herencia o composición.

La respuesta correcta

Ninguno de los dos No hay una bala de plata y no debería serlo.

Por lo tanto, la respuesta correcta es: use tantos modelos de vista como lo requiera el proceso de la interfaz de usuario . Eso es independientemente de las vistas o acciones del controlador.

A veces una acción exige una vista, otra vista. Pero no sigas algunas pautas estrictas que podrían obstaculizar tu desarrollo. Ver modelos vendrá naturalmente a medida que desarrolle su aplicación. Y deberia De lo contrario, puede terminar con vistas irrazonables que se basan en algunas pautas que ha establecido en piedra.

Esta es en realidad una respuesta similar a la de @ DarinDimitrov, pero con una conclusión directa.

Use un modelo diferente para recibir los parámetros de entrada en la acción Post (ni siquiera lo llamo ViewModel en ese caso) que para pasar los parámetros de salida a la vista.

De esa manera puede personalizar exactamente qué parámetros de entrada acepta.

Sigo este enfoque para las formas básicas:

  • Un modelo de vista para el GET.
  • Un modelo de vista para el POST

El modelo GET hereda el modelo POST.

A menudo pasaré un objeto de dominio al constructor del modelo GET y haré 2 cosas con él:

  1. Rellene las propiedades del modelo POST con datos del objeto de dominio.
  2. Encapsule el objeto de dominio como una variable local en el modelo GET. Uso esto para mostrar algunos datos (solo lectura) del objeto de dominio. Ahorra un poco de esfuerzo. Algunas personas te dirán que no hagas esto.