Dans MVVM doit le ViewModel ou modèle implémenter INotifyPropertyChanged ?

Question

La plupart des MVVM exemples que j'ai travaillé ont eu le Modèle implémenter INotifyPropertyChanged, mais Josh Smith CommandSink exemple le ViewModel implémente INotifyPropertyChanged.

Je suis toujours sur le plan cognitif rassembler les MVVM concepts, donc je ne sais pas si:

• vous devez mettre le INotifyPropertyChanged dans le ViewModel pour obtenir CommandSink de travail
• c'est juste une aberration de la norme et il n'a pas vraiment d'importance
• vous devriez toujours avoir le Modèle implémenter INotifyPropertyChanged et c'est juste une erreur qui devrait être corrigé si ce rapport a été élaboré à partir d'un exemple de code pour une application

Quelles ont été les expériences des autres sur MVVM projets sur lesquels vous avez travaillé?

Answer 1

Je suis en total désaccord avec l'idée que le Modèle ne doit pas mettre en œuvre l' INotifyPropertyChanged. Cette interface n'est pas de l'INTERFACE utilisateur spécifique! Il informe simplement d'un changement. En effet WPF fortement l'utilise pour identifier les changements, mais cela ne signifie pas qu'il est une interface utilisateur. Je le comparerais le commentaire suivant "Un pneu est un accessoire de voiture". Assurez-vous qu'il est, mais les vélos, les bus, etc également l'utiliser. En résumé ne pas prendre cette interface une INTERFACE chose.

Cela dit, il n'est pas nécessaire, les moyens, je ne belive dans le Modèle de fournir des notifications. En fait, en règle générale, le modèle ne doit pas implémenter cette interface, sauf si cela est nécessaire. Dans la plupart des cas où aucun serveur de données est poussé à l'application cliente, le modèle peut être obsolète. Mais si l'écoute des données sur les marchés financiers, alors je ne vois pas pourquoi le modèle ne peut pas mettre en œuvre l'interface. Comme un exemple, que faire si j'ai un non-logique de l'INTERFACE utilisateur comme un service qui s'reçoit un cours acheteur ou vendeur pour donner de la valeur, il émet une alerte par le biais d'un e - mail ou passe une commande, alors que cela pourrait être une solution propre.

Cependant, il existe différentes façons de réaliser des choses, mais je serais toujours en faveur de la simplicité et d'éviter la redondance.

Ce qui est mieux? La définition des événements sur une collection de ou des changements de propriété sur la vue-modèle et à la propager au modèle ou d'avoir le point de vue intrinsèque à jour du modèle (par le biais de la Vue-Modèle)?

Bas de ligne à chaque fois que vous voyez quelqu'un qui prétend que "vous ne pouvez pas faire ceci ou cela" c'est comme un signe qu'ils ne savent pas de quoi ils parlent.

Cela dépend vraiment de votre cas, et en fait MVVM est un cadre avec beaucoup de questions et je suis encore à voir un commum de mise en œuvre de MVVM travers le conseil d'administration.

Je souhaite avoir plus de temps à expliquer les nombreuses saveurs de MVVM et des solutions à des problèmes communs - pour la plupart fournis par d'autres développeurs, mais je suppose que je vais avoir à faire à un autre moment.

Answer 2

Je dirais au contraire, j’ai toujours mis mon INotifyPropertyChanged sur mon ViewModel - vous ne voulez vraiment pas être polluantes votre modèle avec une assez WPF caractéristique spécifique comme INotifyPropertyChanged, qui étoffe devrait siéger dans le ViewModel.

Je suis sûr que d’autres seraient en désaccord, mais c’est la façon dont je travaille.

Answer 3

Dans M-V-VM le ViewModel toujours (Modèle pas toujours) met en œuvre INotifyPropertyChanged

Découvrez le M-V-VM Modèle de Projet/Trousse de http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx. Il utilise l' DelegateCommand pour la commande et il doit être un excellent modèle pour vous-M-V-VM projets.

Answer 4

Je pense que MVVM est très mal nommée et en appelant le ViewModel un ViewModel provoque de nombreux manquer une caractéristique importante de l'architecture bien conçue, qui est un DataController qui contrôle les données, peu importe qui est en train de se toucher.

Si vous pensez à la Vue-Modèle plus comme un DataController et de mettre en œuvre une architecture où votre DataController est le seul élément qui touche les données, alors vous ne serait jamais toucher directement les données, mais toujours utiliser la DataController. Le DataController est utile de l'INTERFACE utilisateur, mais pas nécessairement seulement pour l'INTERFACE utilisateur. C'est pour la couche métier, couche d'INTERFACE utilisateur, etc...

DataModel -------- DataController ------ View
                  /
Business --------/

Vous vous retrouvez avec un modèle comme celui-ci. Même l'entreprise ne devrait pas toucher les données en utilisant le ViewModel. Alors votre dilemme juste s'en va.

Answer 5

Il dépend de la façon dont vous avez mis en œuvre de votre modèle. Mon entreprise utilise des affaires objets semblables à Lhotka de l'AAPC objets et de faire un large usage de INotifyPropertyChanged à travers le modèle d'affaires.

Notre moteur de validation s'appuie fortement sur le fait que les propriétés de changement par le biais de ce mécanisme, et il fonctionne très bien. Évidemment, si vous êtes en utilisant une mise en œuvre différente des affaires autres que celles des objets où la notification de changements n'est pas aussi critique pour le fonctionnement, vous pouvez avoir d'autres méthodes pour la détection de changement dans votre modèle d'affaires.

Nous avons aussi des Modèles de Vue que de propager les modifications à partir du Modèle en cas de besoin, mais le point de Vue des Modèles eux-mêmes sont à l'écoute pour le Modèle sous-jacent changements.