Je m'excuse pour la longue question, elle se lit un peu comme une diatribe, mais je promets que ce n'est pas! J'ai résumé ma (mes) question (s) ci-dessous
Dans le monde MVC, les choses sont simples. Le modèle a un état, la vue montre le modèle et le contrôleur fait des choses avec / avec le modèle (en gros), un contrôleur n'a pas d'état. Pour faire des choses, le contrôleur a des dépendances sur les services Web, le référentiel, le lot. Lorsque vous instanciez un contrôleur, vous vous souciez de fournir ces dépendances, rien d'autre. Lorsque vous exécutez une action (méthode sur Controller), vous utilisez ces dépendances pour récupérer ou mettre à jour le modèle ou appeler un autre service de domaine. S'il y a un contexte, par exemple, comme un utilisateur souhaite voir les détails d'un élément particulier, vous passez l'ID de cet élément comme paramètre à l'action. Nulle part dans le contrôleur il n'y a de référence à un état. Jusqu'ici tout va bien.
Entrez MVVM. J'adore WPF, j'adore la liaison de données. J'adore les frameworks qui rendent la liaison de données à ViewModels encore plus facile (en utilisant Caliburn Micro atm). Je pense cependant que les choses sont moins simples dans ce monde. Faisons l'exercice à nouveau: le modèle a l' état, la vue montre la ViewModel et le ViewModel fait des choses à / avec le modèle (essentiellement), un ViewModel n'ont l' état! (à préciser, peut - être il délègue toutes les propriétés à un ou plusieurs modèles, mais cela signifie qu'il doit avoir une référence au modèle d' une façon ou d'une autre, ce qui est l' état en soi) Pour fairele ViewModel a des dépendances sur les services Web, le référentiel, le lot. Lorsque vous instanciez un ViewModel, vous vous souciez de fournir ces dépendances, mais aussi l'état. Et cela, mesdames et messieurs, m'agace sans fin.
Chaque fois que vous avez besoin d'instancier un à ProductDetailsViewModel
partir du ProductSearchViewModel
(dont vous avez appelé le ProductSearchWebService
qui à son tour est revenu IEnumerable<ProductDTO>
, tout le monde est toujours avec moi?), Vous pouvez faire l'une des choses suivantes:
- appel
new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);
, c'est mauvais, imaginez 3 autres dépendances, cela signifie que vousProductSearchViewModel
devez également assumer ces dépendances. Changer le constructeur est également douloureux. - appel
_myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);
, l'usine n'est qu'un Func, ils sont facilement générés par la plupart des frameworks IoC. Je pense que c'est mauvais parce que les méthodes Init sont une abstraction qui fuit. Vous ne pouvez pas non plus utiliser le mot clé readonly pour les champs définis dans la méthode Init. Je suis sûr qu'il y a quelques autres raisons. - appelez
_myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO);
donc ... c'est le modèle (fabrique abstraite) qui est généralement recommandé pour ce type de problème. Je pensais que c'était génial car il satisfait mon envie de frappe statique, jusqu'à ce que je commence à l'utiliser. Je pense que la quantité de code passe-partout est excessive (vous savez, à part les noms de variables ridicules que j'utilise). Pour chaque ViewModel qui nécessite des paramètres d'exécution, vous obtiendrez deux fichiers supplémentaires (interface d'usine et implémentation), et vous devrez taper les dépendances non liées à l'exécution comme 4 fois supplémentaires. Et chaque fois que les dépendances changent, vous pouvez également les changer en usine. J'ai l'impression que je n'utilise même plus de conteneur DI. (Je pense que Castle Windsor a une sorte de solution pour cela [avec ses propres inconvénients, corrigez-moi si je me trompe]). - faire quelque chose avec des types anonymes ou un dictionnaire. J'aime ma saisie statique.
Donc voilà. Mélanger l'état et le comportement de cette manière crée un problème qui n'existe pas du tout dans MVC. Et j'ai l'impression qu'il n'y a actuellement pas de solution vraiment adéquate à ce problème. J'aimerais maintenant observer certaines choses:
- Les gens utilisent réellement MVVM. Donc, soit ils ne se soucient pas de tout ce qui précède, soit ils ont une autre brillante solution.
- Je n'ai pas trouvé d'exemple détaillé de MVVM avec WPF. Par exemple, l'exemple de projet NDDD m'a énormément aidé à comprendre certains concepts DDD. J'aimerais vraiment que quelqu'un me pointe vers quelque chose de similaire pour MVVM / WPF.
- Peut-être que je fais mal MVVM et que je devrais renverser ma conception. Peut-être que je ne devrais pas avoir ce problème du tout. Eh bien, je sais que d'autres personnes ont posé la même question, donc je pense que je ne suis pas le seul.
Résumer
- Ai-je raison de conclure que le fait que le ViewModel soit un point d'intégration pour l'état et le comportement est la raison de certaines difficultés avec le modèle MVVM dans son ensemble?
- L'utilisation du modèle d'usine abstrait est-elle la seule / meilleure façon d'instancier un ViewModel de manière statique?
- Existe-t-il quelque chose comme une implémentation de référence approfondie disponible?
- Est-ce que le fait d'avoir beaucoup de ViewModels avec un état / comportement est une odeur de conception?