mejor práctica para lo que está en un modelo de vista

Question

Me pregunto si es una buena idea o mala, colocando cosas como una lista de países en ViewModel, para vincular a una lista desplegable? Por ejemplo, en la página de registro de un sitio.

Tenía la impresión de que se suponía que un ViewModel representaba una instancia del formulario rellenado, pero creo que puedo estar equivocado ya que he visto a otras personas poner cosas como listas en su ViewModel.

¿No sería mejor colocarlo en una clase estática en alguna parte y llamar directamente desde la Vista?

Me gusta CommonData.ListCountries(); y luego usando Lambda para convertir a la lista de elementos SelectList en la vista Directamente?

Answer 1

Como se ha dado cuenta, hay una variedad de formas de lograr su objetivo. Si bien el MVC design pattern alienta a ciertas organizaciones de aplicaciones a organizar sus modelos, vistas y controladores es, en última instancia, una cuestión de preferencia.

Scott Allen explica su preferencia para tratar con ASP.NET MVC drop down lists en una publicación de blog. Scott usa un método de extensión para convertir un enumerable de un tipo complejo en un IEnumerable<SelectListItem> en su modelo. A continuación, describe que en la publicación posterior, ASP.NET MVC no devolverá el IEnumerable<SelectListItem> que envió a la vista, sino solo el valor que el usuario seleccionó. Luego sugiere que utilizar dos modelos puede simplificar las cosas.

Esta es una descripción razonable de lo que me refiero a ViewModels y FormModels. Un ViewModel lleva los datos de visualización a la vista y un FormModel se utiliza para llevar los datos recopilados a una acción del controlador. Para más información:

• ViewModels contiene datos que ayudan a visualizar. Al organizar mis ViewModels de esta manera puedo colocar toda la información necesaria para representar una vista particular en un modelo asociado. Esto me impide tener que usar ViewData para cualquier cosa que no sea realmente temporal.
• FormModels se utilizan para recopilar la información del usuario. Los FormModels (casi) nunca contienen referencias a otros tipos complejos y están formados por primitivas, DateTimes y cadenas.

En cualquier caso, tengo una regla difícil para never reuse a model for a different view. Tener sus modelos estrechamente alineados con las vistas utilizadas para representarlos hace que sus vistas sean más fáciles de escribir. No tiene que preocuparse por cosas como los métodos estáticos porque sus modelos deberían llevar datos a sus vistas asociadas en una forma que les resulte fácil de procesar. Las herramientas como AutoMapper pueden ayudar a "aplanar" objetos de dominio en modelos con fines de visualización.

Para la caja lectura adicional: ASP.NET MVC terminology is tripping me up - why 'ViewModel'?

Answer 2

Sean cuales sean los datos que su Vista necesite, colóquelos en el ViewModel.

De la manera en que lo veo, una vez que su vista pasa por el proceso de renderizado, debe tener toda la información que necesita del Modelo al que está vinculado.

Si comienza a utilizar métodos auxiliares, la Vista "regresa al controlador" en cierto sentido. Los métodos de extensión/ayuda están bien para formatear, etc., pero no deben llamar a través del modelo.

No olvide que también tiene ViewData (básicamente HttpContext.Current.Items, lives for single request), que es un mecanismo de almacenamiento liviano que se puede usar para compartir datos en vistas parciales (por ejemplo).