Pourquoi MVVM et quels sont ses principaux avantages?

Je vais vous montrer particulièrement utile vidéo par Jason Dolinger.

À venir à partir d'un WinForms monde, la mise en œuvre de toute MVX style de motif qui semblait de plus de tracas que ce qu'il valait, mais après avoir travaillé avec WPF pour un couple d'années maintenant, je peux honnêtement dire que je n'aurais pas envisager quelque chose de moins. Le paradigme est pris en charge hors de la boîte.

Tout d'abord, le principal avantage est de permettre une véritable séparation entre le view et model. Ce que cela signifie en termes réels, c'est que si votre modèle a besoin de changement, il peut, sans le point de vue de devoir et vice-versa.

Deuxièmement, si votre model peut contenir toutes les données que vous pourriez avoir besoin dans votre view, vous pouvez abstraite que les données de telle manière que votre model ne prend pas en charge. Par exemple, disons que votre modèle contient une propriété de date. Dans le modèle, il peut exister uniquement comme un DateTime objet, mais votre point de vue pourrait vouloir présenter dans une manière complètement différente. Sans le viewmodel vous feriez soit de dupliquer la propriété dans la model à l'appui de la consulter ou de modifier la propriété qui pourrait sérieusement obscurcir le "modèle".

Vous pouvez également utiliser un viewmodel pour agréger les parties de votre modèle qui existent dans des classes séparées/bibliothèques afin de faciliter une interface fluide pour le view à traiter. C'est très peu probable que vous aurez envie de travailler avec les données dans votre code, de la même manière que les utilisateurs veulent ou voudront que les données présentées à eux.

Sur le dessus de cela, vous obtenez le soutien automatique à deux sens de la liaison de données entre le view et viewmodel.

Il n'y a vraiment tout un tas d'autres choses que je pourrais bang sur le sujet, mais Jason dire qu'il loin mieux que je pouvais donc, mon conseil est de regarder la vidéo. Après quelques jours de travail comme cela, vous vous demanderez comment vous avez jamais eu sans elle.

Bonne chance.

WPF a une meilleure liaison de données que n'importe quel autre framework d'INTERFACE, qui MVVM serait indisciplinés sans

MVVM fournit à l'unité de la testabilité et excellente visibilité à l'agnosticisme, qui en font une bonne chose d'utiliser

Personnellement, je vois MVVM pas comme un avantage, mais comme une obligation pour ceux qui veulent l'utiliser WPF fonctionnalités intéressantes.

WPF est très très très construit avec la liaison de données à la base, pour permettre la séparation de l'INTERFACE utilisateur à partir du Modèle. Mais le moyen de la liaison de données est réalisé techniquement en WPF est un peu spéciale, car elle est liée à des classes comme:

• DependencyProperty
• INotifyPropertyChanged
• ObservableCollection

De ce fait, vous ne pouvez pas vraiment écrire un modèle de la façon dont vous voulez à l'aide de la norme .NET de la technologie. Par exemple, le WPF TreeView est presque impossible de les utiliser w/o à l'aide de la liaison de données et des modèles. Vous ne pouvez pas remplir tout simplement comme vous le feriez à partir d'un modèle générique en Winforms par exemple. Il doit être lié à un modèle hiérarchique à l'aide de ObservableCollection pour représenter les enfants d'un nœud.

Disons donc que V représente le code XAML et le code-behind de contrepartie (il est donc liée à WPF comme une technologie), et disons que M représente votre modèle (il n'est donc pas liée à WPF technologie d'INTERFACE utilisateur de toute façon).

Bien, vous n'aurez jamais ce travail correctement sous WPF avec seulement ces V & M.

Vous doit ajouter quelque chose entre les deux. Quelque chose qui WPF-compatible et qui comprend votre modèle. Quelque chose qui parle DependencyProperty, ObservableCollection et INotifyPropertyChanged. C'est ce qu'on appelle une machine virtuelle.

Comme une note de côté, une alternative à MVVM est de construire une V & M (w/o VM plomberie) combinaison avec M étant WPF-compatible, mais toujours avec une raisonnable de l'INTERFACE utilisateur de l'indépendance. Historiquement, ObservableCollection a été dans le WindowsBase.dll de l'assemblée (qui a été livré avec WPF), donc on avait vraiment bizarre de se lier à un modèle générique pour quelque chose lié à une technologie d'INTERFACE utilisateur. C'est repoussé à System.dll depuis. Même alors, il est parfois difficile de garder un pur VM modèle w/o peaufiner le M spécifiquement pour WPF...