Pourquoi MVVM et quels sont ses principaux avantages ?

Question

Pourquoi préférer MVVM à MVC ou MVP dans le cadre de WPF ?

Quel avantage supplémentaire obtenons-nous en l'utilisant ?

Edit :

Pour être honnête, aujourd'hui, j'ai eu un entretien et on m'a posé cette question. J'ai répondu comme INotifyPropertyChanged , ICommand, IValue Convertor mais il n'était pas satisfait. Par conséquent, j'ai posé cette question

Merci d'avance

Answer 1

Je vais vous indiquer un site particulièrement utile vidéo par Jason Dolinger.

Venant d'un monde WinForms, la mise en œuvre de tout modèle de style MVX me semblait plus compliquée qu'elle n'en valait la peine, mais après avoir travaillé avec WPF pendant quelques années maintenant, je peux dire honnêtement que je n'envisagerais rien de moins. L'ensemble du paradigme est pris en charge dès la sortie de la boîte.

Tout d'abord, l'avantage clé est de permettre une véritable séparation entre le view et model . Concrètement, cela signifie que si votre modèle doit être modifié, il peut l'être sans que la vue ne doive l'être et vice-versa.

Deuxièmement, alors que votre model peut contenir toutes les données dont vous pourriez avoir besoin dans votre view vous voudrez peut-être abstraire ces données de manière à ce que votre model n'est pas prise en charge. Par exemple, disons que votre modèle contient une propriété de date. Dans le modèle, elle peut exister uniquement en tant que DateTime mais votre vue peut vouloir le présenter d'une manière complètement différente. Sans le viewmodel vous devrez soit dupliquer la propriété dans le fichier model pour soutenir la vue ou modifier la propriété, ce qui pourrait sérieusement obscurcir le "modèle".

Vous pouvez également utiliser un viewmodel pour regrouper les parties de votre modèle qui existent dans des classes/bibliothèques distinctes afin de faciliter une interface plus fluide pour le view à gérer. C'est très Il est peu probable que vous souhaitiez travailler avec des données dans votre code de la même manière qu'un utilisateur souhaitera ou voudra que ces données lui soient présentées.

En plus de cela, vous bénéficiez de la prise en charge de la liaison automatique bidirectionnelle des données entre l'interface utilisateur et l'interface utilisateur. view et viewmodel .

Il y a vraiment tout un tas de choses supplémentaires dont je pourrais parler, mais Jason dit tout. loin mieux que je ne pourrais le faire, donc mon conseil est de regarder la vidéo. Après quelques jours de travail comme ça, vous vous demanderez comment vous avez pu vous en passer.

Bonne chance.

Answer 2

Ce sont des mines spécifiques à MVVM

1. Augmente la "mélangeabilité" de vos vues. (possibilité d'utiliser Expression Blend pour concevoir des vues). Cela permet une séparation des responsabilités dans les équipes qui ont la chance d'avoir un concepteur et un programmeur... chacun peut travailler indépendamment de l'autre.
2. "Logique de vue sans regard . Les vues sont agnostiques par rapport au code qui s'exécute derrière elles, ce qui permet de réutiliser la même logique de vue dans plusieurs vues ou de réorganiser ou remplacer facilement une vue. Séparer les préoccupations entre le "comportement" et le "style".
3. Pas de code dupliqué pour mettre à jour les vues . Dans le code-behind, vous verrez beaucoup d'appels à "myLabel.Text = newValue" saupoudrés partout. Avec MVVM, vous pouvez être sûr que la vue est mise à jour de manière appropriée en définissant simplement la propriété sous-jacente et tous les effets secondaires de la vue.
4. Testabilité . Puisque votre logique est complètement indépendante de votre vue (pas de références à "myLabel.Text"), les tests unitaires sont facilités. Vous pouvez tester le comportement d'un ViewModel sans impliquer sa vue. Cela permet également le développement piloté par les tests du comportement de la vue, ce qui est presque impossible en utilisant le code-behind.

Les deux autres modèles sont vraiment distincts en termes de préoccupations qu'ils abordent. Vous pouvez utiliser MVVM avec MVP et MVC (la plupart des bons exemples qui existent le font sous une forme ou une autre).

En fait, MVP (avec une vue passive, plutôt qu'un contrôleur superviseur) n'est en fait qu'une variante de MVVM, à mon avis.

Answer 3

WPF a une meilleure liaison de données que n'importe quel autre cadre d'interface utilisateur, sans laquelle MVVM serait incontrôlable.

MVVM offre une testabilité unitaire et un excellent diagnostic de la vue, ce qui en fait une bonne chose à utiliser.

Answer 4

Les deux principaux avantages sont la prise en charge intégrée de ICommand et INotifyPropertyChanged. L'utilisation de MVVM facilite grandement le câblage des commandes et l'intégration des données dans l'interface utilisateur WPF. Les choses fonctionnent tout simplement.

Answer 5

La capacité du code XAML à lier des données, ainsi que l'existence de déclencheurs, briseront les modèles MVP et MVC.