¿Cómo nombras tus clases de ViewModel?

Question

¿Qué tipo de convención de nomenclatura es apropiada para las clases de ViewModel?

Ejemplo: para HomeController, ¿Vista de índice? HomeIndexViewModel no parece correcto.

Answer 1

EmployeesViewData.

Eso es lo que uso y lo que he visto en las aplicaciones de muestra también.

Acerca de su ejemplo agregado: Imho el nombre de la clase debe especificar qué tipo de datos contiene. ".... IndexViewData" no tiene sentido. ¿Qué se muestra exactamente en esa página? Intenta resumirlo en 1 o 2 palabra (s) y agrega 'ViewData' detrás de él.

O bien simplemente tome el nombre del controlador y suelte el "índice". HomeViewData me parece bien.

Answer 2

Prefiero HomeViewModel, o usando el ejemplo de empleado anterior, CreateEmployeeViewModel, EditEmployeeViewModel, etc. La idea es que el "ViewModel" enfatiza el hecho de que estamos tratando problemas de presentación, y desambigua los ViewModels de cualquier modelo de dominio de objetos que puedes tener.

Answer 3

Intento mantener mis nombres de modelo de presentación independientes del tipo de presentación que se presentarán. Puedo usar mi objeto modelo para una vista ASP.NET inicialmente, pero más tarde también puedo usarlo en una aplicación WCF o WinForms. Trato de nombrar mis modelos de tal manera que, lógicamente, describen lo que contienen, sin enturbiar con ellos "ViewData", "modelo de vista", "Modelo", etc.

Ejemplos:

ProductsWithPageInfo 
ProductWithAttributesAndTags 
ClientAndBillingDetail 
UserAccountWithAssociatedGroups 

Etc.

Answer 4

He estado usando el término Envelope como parte de mis nombres, el cual comencé a usar poco antes de leer el capítulo 1 del libro de Wrox y descubrí que el término más comúnmente aceptado es ViewModel.

Sin embargo, estos ViewSopes que creo son solo para una encapsulación muy simple cuando tengo dos o más modelos fuertemente tipados (normalmente no relacionados) que me gustaría entregar a mi View. Lo hacen no contienen cualquier otra funcionalidad --- el sobre está destinado solo como mecanismo de entrega en este sentido, mientras que el término ViewModel, para mí, parece menos descriptivo de cómo lo estoy usando, y también posiblemente más ambiguo en cuanto a cuál es su verdadero propósito

Podría crear, por ejemplo, una clase CustomerUpdateEnvelope que existe únicamente para entregar un objeto Customer y un objeto NewsTicker no relacionado, por ejemplo, a mi vista de actualización del cliente.

Answer 5

uso el siguiente patrón porque es clara e inequívoca:

• Modelo: Foo
• Vista: FooView
• modelo de vista: FooViewModel

Answer 6

bastante tarde para este hilo en particular, pero He escrito algunas sugerencias un poco más detalladas sobre ViewModel naming conventions en una publicación de blog, que puede ser útil para otros.