Je développe une demande de prisme WPF, et tout fonctionne bien. Mes modèles de vue ont toutes des interfaces, qui sont injectées par mef.
Cependant, je ne comprends pas vraiment l'avantage des interfaces pour voir les modèles. Après tout, une vue est liée à son modèle de vue, alors je pense qu'il n'y aura jamais d'autres implémentations.
En réalité, j'ai aussi des interfaces pour mes points de vue. Il semble que cela soit aussi trop exclu?
Donc, ma question est la suivante: ne peut-je pas simplement supprimer toutes les interfaces de la vue et afficher les interfaces du modèle et injecter les vues et afficher les modèles directement? Y a-t-il des raisons de conserver des interfaces pour les vues et de voir les modèles?
thx, L
3 Réponses :
La plus grande raison que je puisse penser pour des interfaces pour les images de vue serait que vous pouvez écrire des simulacres qui implémentent ces interfaces à utiliser pendant les tests unitaires. Étant donné qu'un point de vue peut parler à un autre, il vous permet d'associer le comportement du deuxième viewModels lors du test du premier.
Le motif MVVM permet de tester plus facilement les classes car il sépare les données et le contrôle de la couche d'interface utilisateur (qui est plus difficile à rédiger des tests d'unité pour). Personnellement, je n'écris pas des interfaces pour mes points de vue.
Interfaçage Votre viewModels vous donne l'avantage de les moquer dans un test, interfaçage de vos points de vue ressemble à des surennes. Vous ne échangerez pas vos points de vue et vos tests d'interface utilisateur peuvent être effectués sur des simulacres de votre viewModel afin que vous n'ayez pas vraiment besoin de les interfacer, je pense.
Pourquoi se moquer de vos images de vue en test? Je viens d'utiliser le point de vue actuel.
Je me moquerais de la vueModels pour y mettre des attentes. De cette façon, je sais comment les vues doivent regarder lors de la tester. Je pourrais également écrire un test qui remplirait les images de vue avec des données et les fournirait pendant les tests. C'est vraiment la même chose la même chose.
Merci, j'ai donc raison de dire qu'il n'y a pas vraiment beaucoup de valeur ajoutée dans InterfaSing View Models, à cause de: 1. Nous n'avons pas besoin de se moquer de leur module, car c'est le modèle de vue lui-même qui doit être testé. 2. Par conséquent, la moqueur d'un modèle de sous-vue n'a pas beaucoup de sens, car nous souhaitons également tester l'une. 3. Afin de tester les points de vue, nous remplissons simplement les modèles de vue réels avec des données. 4. Comme une vue est couplée à son modèle de vue, il y aura toujours une implémentation.
C'est une overcilleuse. Je comprends que vous voudrez peut-être vous moquer de vos points de vue, mais je pense qu'il est plus important d'être pratique. De plus, pourquoi auriez-vous même besoin de se moquer de vos images de vue? Toute logique qui doit être moquée doit être mise dans une classe de service IMHO.
C'était bien aussi ma première pensée. Il semble que l'avantage est que, si vous avez plusieurs modèles d'affichage, vous pouvez en tester l'un et se moquer des autres. Je me demande simplement si je le ferai jamais ... la plupart des logiques sont en effet dans des «services» qui sont injectés et peuvent être remplacés mes meubles de mise en œuvre.