0

I am trying to understand the MVVM concept better and I am struggling with the model and viewmodel relation.

Can I say that: The Model is not aware of the ViewModel as the ViewModel is not aware of the View?

Correct me if I am wrong, considering a simple WPF application that displays some string we should have:

View: XAML TextBlock bound to string property text1
      XAML.CS instantiates ViewModel vModel

ViewModel: has property text1 
           implements INotifyPropertyChanged notifying View of its changes
           instantiates Model mModel 

Model: has property string text1
       ?? implements INotifyPropertyChanged notifying ViewModel of its changes ??

Here I am confused about the last part. If the whole logic happens in model, e.g string manipulation, how to handle notification from Model in ViewModel?

Is it possible that ViewModel_PropertyChanged can access and change it's property value through property name? And I don't mean:

if (e.PropertyName == "text1")

As it will be a nightmare if we have a lot of properties

Assuming that the property has the same name in Model and ViewModel we could do:

    // Model PropertyChanged Handler
    private void mainModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        NotifyPropertyChanged(e.PropertyName);
    }


    // ViewModel PropertyChanged Notifier 
    public event PropertyChangedEventHandler PropertyChanged;

    private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

Then ViewModel could hold a pass-thought property

    public string text1
    {
        get { return mModel.text1; }
        set { }
    }

But is that correct? And what if we need this property to be changed from UI?:

    public string text1
    {
        get { return mModel.text1; }
        set
        {
            if (mModel.text1 != value)
            {
                mModel.text1 = value;
                NotifyPropertyChanged("text1"); // ??
            }
        }
    }

mModel.text1 = value; - this will notify everybody including UI about the change that it has made NotifyPropertyChanged("text1"); // ?? - this will reapeat this notification

If the ViewModel is holding only this pass-through properties, what is the need for it? Is the ViewModel needed only to make some different sense of the Model properties to display them in UI?

Sorry for the vast post, hope someone can help me.

Sam Hicks
  • 31
  • 1
  • 7
  • 1
    Those are all good questions, but I'm afraid that SO is not the right place to ask them. You should do some more research (you've clearly done some already) and come back here if you have more specific questions. But just so you know, there are a lot of libraries and frameworks out there that address those MVVM problems, e.g. MVVM light or DevExpress.Mvvm.Free – Sentry Aug 02 '18 at 13:05

1 Answers1

-1

The role of the viewmodel is to shape, transform or manipulate the data. For example this could mean making available a subset of a bigger list, flattening out some properties from a nested data entity or transforming numeric/textual values as an enumeration. There should be no view specific information stored in the viewmodel (e.g. SelectedIndex), that view related info should be stored in properties in the code behind of the view (you can still bind to it).

The biggest thing people get wrong with their interpretation of MVVM is what constitutes a "model" - this is a mistake that Michael has made in his answer. In MVVM the model is anything that isn't the view or viewmodel. A data class is part of the model but isn't a model (not in the way it is in MVC or some other patterns). In fact in MVVM you shouldn't call data classes "models", it is more semantically correct to call them data entities or business entities. The "model" can encompass several layers if you are following an n-tier architecture.

To clarify Michael's diagram:

                    |    
View -> ViewModel ->| BL -> DAL -> Data Entities  
                    |  
                    | -> "the model"  
                    |

This previous answer of mine may be helpful: In the MVVM design pattern, should models contain other models? - it explains this approach and has a reference link back to the MSDN doco.

slugster
  • 49,403
  • 14
  • 95
  • 145
  • @MichaelPuckettII wow, a bit of a barrage there. Go and study some more architectural patterns, and don't forget to read the [official MSDN doco I linked to](https://learn.microsoft.com/en-us/previous-versions/msp-n-p/hh848246(v=pandp.10)) in my other answer. If you don't like it then take it up with Microsoft. – slugster Aug 04 '18 at 07:33
  • @MichaelPuckettII The diagram of yours that I said was mistaken was the `View -> ViewModel -> DAL -> Model` one - the DAL is part of the model. It's a common misconception and doesn't matter so much in small applications but it matters plenty in large enterprise solutions where the "model" is typically several layers. – slugster Aug 04 '18 at 07:34
  • @MichaelPuckettII Quote: "*The model in MVVM is an implementation of the application's domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.*" – slugster Aug 04 '18 at 07:35