Convenzioni di denominazione relative alla visualizzazione di modelli da evitare nomi lunghi

Question

Sto creando visualizza modelli per ciascuna schermata dell'applicazione ASP.NET MVC. Ho inserito tutta la logica per la creazione di un modello di visualizzazione in una classe builder. Di solito, esiste una logica speciale per la conversione degli oggetti dati in modelli di visualizzazione, inclusi aggregazione, filtraggio e ordinamento. Ogni costruttore riceve un set di dipendenze , che è un oggetto che contiene le proprietà per ogni dipendenza (repository, altri builder, ecc.).

Il problema è che i miei nomi stanno diventando davvero lungo. Un insieme di dipendenza di solito hanno un nome composto in questo modo:

vista-model-name + Builder + DependencySet

Visualizza i modelli di solito hanno nomi composti da dove siete attualmente ei bambini. Ad esempio, il mio sistema ha classificato le definizioni del fornitore. Così, al fine di mostrare le definizioni di provider in una categoria, ho un modello di vista chiamato:

CategoryProviderDefinitionListViewModel

Si sarà simile a questo:

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

Così, la mia il costruttore si chiama

CategoriaProviderDefinitionListViewModelBuilder

Quindi, il mio set dipendenza viene chiamato

CategoryProviderDefinitionListViewModelBuilderDependencySet

che si adatta a malapena attraverso lo schermo. Le mie povere dita sono stanche. Inoltre, alcune schermate mostrano quasi gli stessi dati, quindi i loro nomi dei modelli di visualizzazione sono quasi gli stessi. Quando guardo attraverso la mia cartella, diventa davvero difficile trovare le classi specifiche del modello di visualizzazione che sto cercando.

Idealmente, potrei raggruppare le mie classi di modelli di viste insieme, associandole alla vista (s) in cui sono utilizzate. Sarebbe bello evitare le collisioni e rendere i nomi il più brevi possibile, mantenendoli significativi. Qualcuno ha trovato un'organizzazione di convenzione/cartella di denominazione che funziona bene in questo scenario?

Answer 1

Sto usando il suffisso "ViewModel" costantemente per un po 'di tempo e, a dire il vero, a volte lo trovo ridondante. Penso che il raggruppamento di tutte queste classi in un namespace diverso dovrebbe essere sufficiente.

mia comprensione è che questa convenzione è stata adottata per evitare la collisione tra il modello di dominio e classi di vista del modello (ad esempio prodotto vs ProductViewModel). Tuttavia, poiché i tuoi modelli di vista prendono il nome dalle schermate, è molto improbabile che tu abbia una classe con lo stesso nome nel tuo modello di dominio. In effetti, dovrebbe essere davvero discutibile il motivo per cui hai una tale classe nel tuo modello di dominio!:)

Quindi, se il nome del tuo vista del modello qualcosa come ViewProduct (per consentire all'utente di visualizzare/modificare un prodotto), non è necessario chiamare lo ViewProductViewModel. Vedi dove sto andando?

Di conseguenza, la classe Builder potrebbe semplicemente essere chiamato ViewProductBuilder invece di ViewProductViewModelBuilder.

Per quanto riguarda il set di dipendenze, non sono sicuro di quale sia la logica alla base di questo. Ma a me sembra inutile. Se il builder ha dipendenze con altri oggetti, è necessario iniettare dipendenze nel costruttore del builder, invece di incapsularli in un'altra classe (DependencySet) e quindi passarle in giro.

Se si rileva che il generatore dipende anche da cose e questo è ciò che si sta cercando di nascondere dietro DependencySet, potrebbe essere l'indicazione di un odore di design da qualche altra parte. Se le classi e le loro dipendenze sono progettate in modo appropriato orientato agli oggetti, il comportamento dovrebbe essere distribuito molto bene tra varie classi e nessuna classe dovrebbe avere dipendenza da troppe altre cose. Quindi, nascondere le dipendenze N sotto la classe 1 (DependencySet) sta semplicemente trattando i sintomi non il problema stesso.

Spero che questo aiuto :)

Answer 2

preferisco post-fissaggio miei nomi ViewModel con "DTO". (Dove DTO sta per Data Transfer Object, cioè un oggetto che non fa altro che contenere informazioni)

Questo non è solo per evitare nomi lunghi. Ma mi rende anche in grado di usare gli stessi nomi come Utente, ma sarà chiamato UserDTO, indicando che sto lavorando con un oggetto che fa parte del mio ViewModel, evitando così la denominazione delle collisioni.

Answer 3

Sono tendenzialmente d'accordo con Mosh.

Il suffisso ViewModel diventa ridondante la maggior parte del tempo e mentre a volte è possibile avere nomi di classi corrispondenti, è abbastanza facile da gestire in quanto sono limitati al proprio spazio dei nomi ViewModel. Trovo anche che l'uso dell'alias al namespace dispari mi ferisca il cervello meno del suffisso dei miei nomi di classe su tutta la linea.

Naturalmente nel tuo presentatore/controller potresti avere conflitti di denominazione, ma questo potrebbe essere un segno che devi nominare le tue Visualizzazioni in modo più appropriato, ad es. non Utente ma ViewUser/EditUser.

Per i risultati di ricerca e gli elenchi, è preferibile scomporre qualcosa come IEnumerable anziché IEnumerable. Quest'ultimo spesso significa che si finisce con una classe di modelli di vista utente che diventa una discarica per tutte le proprietà degli utenti che possono o non possono essere necessarie in tutto il progetto. Questa è una delle cose più importanti da tenere d'occhio e se ti trovi in ​​una classe come questa, sei stato sulla pista da qualche parte. Mantieni le tue opinioni e i tuoi modelli di visualizzazione descrittivi e specifici. Se si hanno molti modelli di vista simili, il problema è probabilmente un problema di progettazione più grande; alcuni progettisti hanno la tendenza a reinventare anziché riutilizzare le strutture grafiche esistenti.