Convenciones de nomenclatura sobre modelos de vista para evitar nombres largos

Question

Estoy creando para ver los modelos para cada pantalla en mi aplicación ASP.NET MVC. Puse toda la lógica para crear un modelo de vista en una clase de constructor . Por lo general, existe una lógica especial para convertir los objetos de datos en modelos de visualización, incluidos la agregación, el filtrado y la clasificación. Cada constructor recibe un conjunto de dependencias , que es un objeto que contiene propiedades para cada dependencia (repositorios, otros constructores, etc.).

El problema es que mis nombres están obteniendo realmente de largo. Un conjunto de dependencia por lo general tienen un nombre compuesto de esta manera:

vista-modelo-nombre + + Builder DependencySet

Ver modelos suelen tener nombres compuestos de dónde se encuentra actualmente y los niños. Por ejemplo, mi sistema ha categorizado las definiciones de proveedores. Por lo tanto, con el fin de mostrar las definiciones de proveedor en una categoría, tengo un modelo de vista llamada:

CategoryProviderDefinitionListViewModel

Se verá algo como esto:

public sealed class CategoryProviderDefinitionListViewModel 
{ 
    public long CategoryId { get; set; } 
    public string CategoryName { get; set; } 
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; } 
} 

lo tanto, mi constructor se llama

CategoríaProveedorDefiniciónListaViewModelBuilder

Por lo tanto, mi juego se llama dependencia

CategoryProviderDefinitionListViewModelBuilderDependencySet

que apenas cabe en la pantalla. Mis pobres dedos están cansados. Además, algunas pantallas casi muestran los mismos datos, por lo que sus nombres de modelo de vista son casi los mismos. Cuando busco en mi carpeta, es muy difícil encontrar las clases de modelos de vista específicas que estoy buscando.

Idealmente, podría agrupar mis clases de modelos de vista, asociándolos con la vista (s) donde se usan. Sería bueno evitar colisiones y hacer nombres lo más cortos posible, manteniéndolos significativos. ¿Alguien ha encontrado una organización de convención/carpeta de nombres que funcione bien en este escenario?

Answer 1

He estado utilizando el sufijo "ViewModel" de forma constante durante bastante tiempo y para ser sincero, a veces me resulta redundante. Creo que basta con agrupar todas estas clases en un espacio de nombres diferente.

Mi entendimiento es que esta convención ha sido adoptada para evitar la colisión entre el modelo de dominio y las clases de vista del modelo (por ejemplo producto vs ProductViewModel). Sin embargo, dado que sus modelos de vista llevan el nombre de las pantallas, es muy poco probable que tenga una clase con el mismo nombre en su modelo de dominio. De hecho, debería ser realmente cuestionable por qué tienes esa clase en tu modelo de dominio.:)

lo tanto, si el nombre de su modelo de vista algo así como verProducto (para permitir al usuario ver/editar un producto), no es necesario llamarlo ViewProductViewModel. ¿Ves a dónde voy?

En consecuencia, la clase Constructor simplemente se podría llamar ViewProductBuilder en lugar de ViewProductViewModelBuilder.

En cuanto a su conjunto de dependencias, no estoy seguro de cuál es su razón de ser detrás de esto. Pero para mí parece innecesario. Si su constructor tiene dependencias con otros objetos, necesitará inyectar dependencias en el constructor del generador, en lugar de encapsularlas en otra clase (DependencySet) y luego pasarlas.

Si encuentra que su constructor depende también de las cosas y esto es lo que está tratando de ocultar detrás de DependencySet, entonces podría ser la indicación de un olor de diseño en otro lugar. Si las clases y sus dependencias están diseñadas de una manera adecuada orientada a objetos, el comportamiento debe distribuirse muy bien entre varias clases y ninguna clase debe tener dependencia de muchas otras cosas. Por lo tanto, ocultar esas dependencias N en 1 clase (DependencySet) es simplemente tratar los síntomas, no el problema en sí.

Esperanza esta ayuda :)

Answer 2

prefiero posterior a la fijación de mis nombres ViewModel con "DTO". (Donde DTO significa Data Transfer Object, es decir, un objeto que no hace más que contener información)

Esto no es solo para evitar nombres largos. Pero también me permite usar los mismos nombres como Usuario, pero se llamará UserDTO, indicándome que estoy trabajando con un objeto que es parte de mi ViewModel, y así evitar el nombre de colisiones.

Answer 3

Tiendo a estar de acuerdo con Mosh.

El sufijo de ViewModel se vuelve redundante la mayoría de las veces y, aunque a veces puede tener nombres de clase coincidentes, es bastante fácil de administrar ya que están limitados al espacio de nombres de ViewModel. También encuentro que usar el alias de espacio de nombres impar duele mi cerebro menos que el sufijo de mis nombres de clase en general.

Por supuesto, en su presentador/controlador puede tener colisiones de nombres, pero eso podría ser un signo de que necesita nombrar sus Vistas de forma más adecuada, p. no usuario sino ViewUser/EditUser.

Para resultados de búsqueda y listas, me parece que es mejor exponer algo como IEnumerable en lugar de IEnumerable. Esto último a menudo significa que terminas con una clase de modelo de vista de usuario que se convierte en un vertedero para todas las propiedades de usuario que pueden o no ser necesarias en todo el proyecto. Esta es una de las cosas más importantes a tener en cuenta y si te encuentras en una clase como esta, te has ido de la pista a algún lado. Mantenga sus vistas y vea los modelos descriptivos y específicos. Si tiene muchos modelos de vistas similares, el problema probablemente sea un problema de diseño más grande; algunos diseñadores tienden a reinventar en lugar de reutilizar las estructuras gráficas existentes.