MVVM: is this good practice?

Question

Let's say I have a model that provides a collection of objects that I will display and modify in a graphical interface.

So, we have a model representing the ModelItem collection.

The view is associated with a ViewModel that provides an ObservableCollection for the ViewModelItem. ViewModelItem is a ModelItem view model.

The view contains a ListBox and a DataTemplate. DataTemplate is for items of type ViewModelItem. View DataContext points to an instance of ViewModel. ListBox binds to an ObservableCollection.

I manage all the code.

So far so simple. Question:

Is it permissible to expose a collection to Models as an ObservableCollection? Also, is it acceptable to implement INotifyPropertyChanged in Model and ModelItem?

My concern is that I am messing up the separation between the model and the viewmodel, but then common sense says that there is a mechanism for notifying changes in the elements of my model, allows you to use it ...

Just wanted to get some perspective from others.

thanks

Answer 1

Short answer: YES. Use your notification interfaces on your model when you need to notify about changes. Do not worry about hiding this code. Be pragmatic.

Long answer: My philosophy is this: When implementing MVVM, directly communicate with model objects when there is nothing superfluous. When you need something new (new behavior, properties that the view will use, etc.), you transfer model objects to ViewModel objects. The ViewModel, which does nothing but delegate data from the model, is nothing more than additional code. At the moment when you need to do something with the data received from the model object, you enter a layer.

So, to expand my thoughts further, (and to answer your question more directly), there must be a way to show ViewModel models when something changes. Often these models are immutable, so it does not need this notification mechanism, so this is not necessary. BUT, it also often happens that the model changes. When this happens, the model has two options: use a custom notification method (events, delegates, etc.) or use INotifyPropertyChanged .

If you look at the namespace for INotifyPropertyChanged , it is in System.ComponentModel - not in the view - so I prefer to use it in the model. This is a well-known interface, and you can use it to bind directly to your model from your view. No need to implement anything.

Taking this philosophy one step further, the ObservableCollection is located in System.Collections.ObjectModel , is also view-independent, and implements System.Collections.Specialized.INotifyCollectionChanged , which is also view-independent. In other words, an ObservableCollection was created as a collection that notifies its observers of changes. If you have a model that needs to do this, then ObservableCollection is your tool. It is just convenient (not accidental) that WPF and Silverlight use these interfaces to bind data.

I guess this is a long way of saying, “YES. Use your notification interfaces on your model when you need to notify about changes. Don't worry about how to clone your code with this. Be pragmatic.”

Answer 2

No. It's horrible. Your model does not need to know how it is used. By providing this, this knowledge defeats the MVVM object.
A model should never know that it is used by WPF, winforms, dos console, as a service, or as a lib. If you say this, you are mistaken. It must also be structure independent, not considering whether it is part of MVVM, MVC or MXXX!

Answer 3

Of course, this is acceptable for both. I would even say that it is necessary for both. Your sound mental abilities work great. :)

I would add that if you do not need all the MVVM functions for ModelItem s, you can cut some corners by setting ObservableCollection<ModelItem> instead of ObservableCollection<ViewModelItem> and changing your DataTemplate to fit. This will save you a bit of “preparation code,” so weigh the pros and cons.

Answer 4

Of course, it is acceptable to use a notification of a change in the data model if the data model needs to change the notification. It is also doubtful to use a change notification in the data model just because the user interface needs a change notification.

As a rule, I design a data model as if there was no user interface, and use the presentation model as an abstraction layer that hides the details of the data model implementation from the user interface. On the other hand, in a dynamic application it may happen that the need for notification of changes is quite common, which makes sense to embed it in a data model.