Je crée des modèles pour chaque écran de mon application ASP.NET MVC. Je mettais toute la logique pour créer un modèle de vue dans une classe Builder . Habituellement, il existe une logique spéciale pour convertir les objets de données en modèles, y compris l'agrégation, le filtrage et le tri. Chaque constructeur est passé un ensemble de dépendance Le problème est que mes noms sont les vraiment < / em> long. Un ensemble de dépendances aura généralement un nom composé de cette façon: Vue-Model-Name + Builder + DépendenCyset
Les modèles ont généralement des noms composés d'où vous êtes actuellement et les enfants. Par exemple, mon système a catégorisé définitions de fournisseurs. Ainsi, afin de montrer les définitions de fournisseur dans une catégorie, j'ai un modèle de vue appelé: CatégorieProviderDefinitionListViewModel
Il ressemblera à quelque chose comme ceci: Alors, mon constructeur est appelé CatégorieProviderDefinitionListViewModelBuilder
Donc, mon ensemble de dépendance est appelé CatégorieProviderDéfinitionListViewModelBuilderDependenSet
qui convient à peine sur l'écran. Mes pauvres doigts sont fatigués. De plus, certains écrans montrent presque les mêmes données, de sorte que leurs noms de modèle de vue sont presque identiques. Quand je regarde dans mon dossier, il devient très difficile de trouver les classes de modèle de vue spécifiques que je recherche. Idéalement, je pourrais regrouper mes classes de modèle de vue ensemble, les associer avec la vue (s) où ils sont utilisés. Ce serait bien d'éviter les collisions et de faire des noms aussi courts que possible, tout en les gardant significatif. Est-ce que quelqu'un a trouvé une organisation de convention / dossier de dénomination qui fonctionne bien dans ce scénario?
3 Réponses :
Je l'ai utilisé le suffixe « ViewModel » constamment pendant un certain temps et pour être honnête, je trouve parfois redondant. Je pense que GROUPEMENT toutes ces classes dans un espace de noms différent devrait être suffisant.
Si je comprends bien que cette convention a été adoptée pour éviter la collision entre les classes de modèle modèle de domaine et afficher (par exemple Produit vs ProductViewModel ). Cependant, étant donné que vos modèles d'affichage sont nommés d'après les écrans, il est très peu probable que vous auriez une classe avec le même nom dans votre modèle de domaine. En fait, il devrait être vraiment demander pourquoi vous avez une telle classe dans votre modèle de domaine! :)
Alors, si vous nommez votre point de vue modèle quelque chose comme ViewProduct (pour permettre à l'utilisateur de visualiser / modifier un produit), vous n'avez pas besoin de l'appeler ViewProductViewModel . Voir où je vais?
Par conséquent, votre classe Builder pourrait simplement être appelé ViewProductBuilder au lieu de ViewProductViewModelBuilder .
En ce qui concerne votre jeu de dépendance, je ne sais pas quelle est votre raison d'être derrière tout cela. Mais pour moi, il semble inutile. Si votre constructeur a des dépendances à d'autres objets, vous aurez besoin d'injecter des dépendances dans le constructeur de constructeur, au lieu de les encapsuler dans une autre classe (dependencySet), puis les passer autour.
Si vous trouvez votre constructeur dépend trop de choses peut et c'est ce que vous essayez de cacher derrière dependencySet, alors il pourrait être l'indication d'une odeur de conception ailleurs. Si les classes et leurs dépendances sont conçues dans une bonne manière orientée objet, le comportement doit être distribué très bien entre les différentes classes et pas de classe devrait avoir la dépendance de trop d'autres choses. Donc, cacher ces dépendances N sous 1 classe (dependencySet) est simplement traiter les symptômes non au problème.
Hope cette aide:)
Je préfère post-fixer mes noms de viewModel avec " dto ". (Où DTO signifie un objet de transfert de données, c'est-à-dire un objet qui ne fait que contenir des informations)
Ceci n'est pas seulement pour éviter les noms de longs. Mais cela me permet également d'utiliser les mêmes noms tels que
un DTO est une chose différente mais , pour un début, il est possible d'avoir une DTO et Afficher les modèles dans la même solution.
C'est vrai. Et si cette situation est apparue, je choisirais probablement également une convention de dénomination différente. Mais bon point.
J'ai tendance à être d'accord avec Mosh.
Le suffixe ViewModel devient redondant la majorité de l'époque et, bien que parfois, vous pourriez avoir des noms de classe correspondants, il est assez facile de gérer car ils sont confinés à votre espace de noms de viewModel. Je trouve également que l'utilisation de l'espace d'espace de nom étrange fait mal mon cerveau, moins de suffixer mes noms de classe à travers le tableau.
Bien entendu dans votre présentateur / contrôleur, vous pouvez avoir nommé des collisions, mais cela pourrait être un signe que vous devez nommer votre point de vue de manière plus appropriée, par exemple. Pas utilisateur mais ViewUser / EdiTUser.
Pour les résultats de la recherche et les listes, je trouve qu'il est préférable de briser quelque chose comme IEnumerable au lieu de iEnumerable. Ce dernier signifie souvent que vous vous retrouvez avec une classe de modèle d'affichage de l'utilisateur qui devient un terrain de dumping pour toutes les propriétés de l'utilisateur pouvant ou non être nécessaires sur le projet. C'est l'une des grandes choses à faire attention et si vous vous trouvez avec une classe comme celle-ci, vous êtes parti de la piste quelque part. Gardez vos points de vue et voir les modèles descriptifs et spécifiques. Si vous avez de nombreux modèles de vue similaires, le problème est probablement un problème de conception plus gros; Certains concepteurs ont tendance à réinventer plutôt que de réutiliser les structures graphiques existantes.