Poussez la fonctionnalité ViewModel commune dans une classe de base?

Question

J'utilise MVVM avec Prism et Silverlight. J'ai plusieurs vues différentes d'un modèle. Comme j'écris plus de vues leurs ViewModels semblent reproduire beaucoup de code commun lié à la manipulation de ce modèle. Plutôt que de répéter le même code commun dans toutes les VM, je suis tenté de le repousser dans le modèle (ce qui serait probablement trop mélanger les préoccupations). Ou peut-être dans une classe de base ViewModel commune? Ou peut-être que mes machines virtuelles ont besoin d'un deuxième niveau de «VM partagée» entre elles et le modèle? Cette instance partagée unique, de deuxième niveau-VM, consoliderait le comportement et l'état partagés par les multiples machines virtuelles normales.

Avez-vous des commentaires sur ces problèmes et les approches possibles?

---

Merci pour les commentaires les gars. J'aurais probablement dû vous en dire plus sur le code VM "partagé" spécifique en question.

Je peux voir mettre un peu futur code dans une classe de base VM, mais le particulier code « partagé » Je suis à la recherche semble appartenir à un INotifyPropertyChanged mis en œuvre par le modèle lui-même. Ceci est en partie basé sur ce other thread.

Je ne pense pas que cela viole le SoC, parce que le modèle est intrinsèquement dynamique. Certaines de ses propriétés ne sont valables qu'à certains moments. Cette nature dynamique du modèle n'est pas seulement quelque chose d'important pour l'IU, un test unitaire approprié s'en soucierait également. Par conséquent, ce modèle semble avoir besoin d'un INotifyPropertyChanged.

Un commentaire à ce sujet?

Answer 1

Si le code commun peut être partagé par tous ViewModels, alors il vaut la peine de le mettre dans un type ViewModel de base.

Si le code commun est uniquement partagé par ViewModels qui interagissent avec un modèle particulier, un ViewModel "partagé" est le chemin à parcourir.

Answer 2

J'ai utilisé l'héritage pour ViewModels dans le New York Times Silverlight Kit pour réduire le code répliqué. Regardez CommunityRecentComments et sa classe parente CommunityBase pour un exemple.

Answer 3

La plupart des classes "base ViewModel" dans la variété des frameworks MVVM ont tendance à contenir le support pour INotifyPropertyChanged et généralement une sorte de support pour la réexpédition vers le thread UI. Au-delà, je pense que si vous avez un certain nombre de ViewModels qui partagent des fonctionnalités qui devraient être dans une classe de base, plus j'utilise ce modèle, plus je me trouve en utilisant une hiérarchie peu profonde de ViewModels, un ViewModel de base pour code commun à tous les modèles de vue et généralement une autre classe de base sous celle pour les fonctionnalités communes dans cette zone de l'interface utilisateur. Commandes habituellement communes ou où l'interface utilisateur partage des éléments.

ViewModelBase -> ProductsViewModelBase -> NewProductViewModel

Answer 4

Dans SoapBox Core, qui est entièrement MVVM, je définissais une interface IViewModel, et une classe de base AbstractViewModel qui, comme l'a dit Nigel, tout en œuvre INotifyPropertyChanged. (Notez que SoapBox Core est WPF, pas Silverlight, mais dans ce cas, ce n'est pas un gros problème.) J'ai ensuite défini d'autres interfaces (comme IMenuItem) héritant de IViewModel. et des classes plus abstraites qui fournissent une implémentation de base de ces interfaces.Maintenant, cela représente l'ensemble de l'arborescence ViewModel, mais comme vous l'avez dit, il y a aussi l'arborescence du modèle. J'ai passé presque un an à travailler avec MVVM et voici ma grande révélation: N'écrivez pas un modèle. Si vous construisez l'application à partir de zéro, mettez tout dans le ViewModel, sinon vous finirez par dupliquer une tonne de code.

Les seuls cas où j'ai pris la peine d'avoir un modèle étaient lorsque j'utilisais une bibliothèque tierce qui n'implémentait pas INotifyPropertyChanged et n'était donc pas facilement liée. Je crois que le code auto-généré pour les frameworks d'entités pourrait aussi tomber ici, mais j'ai remarqué que certains frameworks d'entité vous donnent maintenant la possibilité d'implémenter INotifyPropertyChanged dans les entités elles-mêmes.

Sérieusement, nous devrions renommer le modèle ViewModel et en avoir fini avec lui. :)