Le rôle du modèle dans MVVM

Question

J'ai lu quelques articles concernant le rôle du (Data)Model dans le modèle MVVM. Cependant, je n'arrive toujours pas à comprendre ce qui entre dans le modèle.

Le modèle doit-il implémenter INotifyPropertyChanged ? Si oui, quelle est la différence entre la VM et le modèle ?

Si ce n'est pas le cas, un changement dans le modèle ne notifiera pas la VM et la vue qu'il s'est produit. Ainsi, compte tenu de la logique qui entre dans le modèle, il semble évident qu'il devrait notifier le ViewModel de certains de ses changements. Cependant, n'est-il pas étrange d'implémenter INotifyPropertyChanged dans les deux classes ?

Merci beaucoup !

Answer 1

Le modèle met en œuvre votre logique d'entreprise . Le modèle de vue décore votre logique métier dans le but de l'afficher et d'interagir avec elle, dans une vue (interface utilisateur d'une certaine forme, par exemple web, winform, CLI). Donc, non, je ne dirais pas que votre modèle devrait implémenter INotifyPropertyChanged à moins qu'il ne le fasse dans le cadre de votre logique commerciale de base.

Answer 2

D'après un de vos commentaires :

il me semble bizarre que le modèle implémente INotifyPropertyChanged, qui me semble être une classe liée à l'interface utilisateur.

La notification de changement est utilisée dans toutes sortes de contextes, mais pas dans celui de l'interface utilisateur. Par exemple, vous pourriez vouloir attacher un morceau de code de diagnostic qui enregistre des changements spécifiques à un fichier de type TextWriter . Ceci est facilement réalisable sans modification de l'objet de modèle sous-jacent si l'objet implémente la notification de changement.

Mais même dans une application où elle n'est utilisée que pour mettre à jour l'interface utilisateur, ce modèle est toujours pertinent. La notification des modifications étant gérée par le biais d'un événement, l'objet qui génère l'événement est découplé de l'objet qui le gère. Votre modèle ne sait pas, et n'a pas besoin de savoir, quel type d'interface utilisateur l'utilise. Il dit simplement : "En supposant qu'il y ait une interface utilisateur, je dois lui dire, quelle qu'elle soit, que la valeur de cette propriété vient de changer".

Pourquoi existe-t-il un modèle de vue ? Pourquoi ne pas simplement se lier directement au modèle ? En fait, vous puede il suffit de se lier directement au modèle s'il implémente la notification de changement. Dans beaucoup d'applications WPF simples, il n'est pas nécessaire d'avoir un modèle de vue séparé - vous pouvez simplement implémenter la notification de changement dans le modèle et l'appeler un jour. C'est lorsque vous devez découpler l'interface utilisateur de la logique métier sous-jacente et que vous commencez à vous préoccuper de savoir si vous violez ou non le principe de responsabilité unique que le besoin d'un modèle de vue se fait sentir.

Answer 3

Dans certains cas, un modèle doit implémenter INotifyPropertyChanged. Imaginez que vous codiez un client pour ICQ ou quelque chose comme ça. Comment le ViewModel est-il censé savoir que quelqu'un vous a envoyé un message ?

Différence entre Model et ViewModel :

Un ViewModel ne fait que simplifier la sortie d'un modèle. Si le modèle est très simple, un ViewModel n'est pas nécessaire.

Answer 4

Consultez ce post :

Qu'est-ce qui va dans Model dans MVVM ?

Answer 5

Vérifiez si cet article vous aide

http://www.codeproject.com/KB/WPF/MVVMForDummies.aspx