MVVM model instantiation

Question

Following WPF MvvmFoundation, linking the View with the ViewModel has many choices like described on http://www.paulstovell.com/mvvm-instantiation-approaches.

However their example has nothing about how to link the ViewModel with the Model.

Traditionally I created the model first and then one or more views that render it. It seems that MVVM pushes people to create the View, which creates the ViewModel, which create the Model. I hope it's not the case as wiring a complex business model with various ModelView can else be tough.

How do you instantiate your business model classes in MVVM and link them with your ViewModels?

Answer 1

I normally pass Model objects as constructor params to VM. I use App class as the controller which will initialize MainWindow, MainWindowViewModel with the main model. There after the MainWindowViewModel takes care of initializing other VMs with appropriate model objects.

    private void Application_Startup(object sender, StartupEventArgs e)
    {
        mainWindow = new MainWindow();
        mainWindow.DataContext = new MainWindowViewModel(new Model());
        mainWindow.Show();
    }

Answer 2

You create your BusinessModel classes inside your ViewModel.

So in your CustomerViewModel you would say this.CurrentCustomer = new CustomerModel(), and your CustomerView would bind to the CurrentCustomer property on the ViewModel

If you are interested, I wrote up a simple sample using MVVM as an example of how the View, Model, and ViewModel interact.

Answer 3

I use dependency injection/MEF to do this. Just export all of my model classes all the way down the chain, and have them imported for me automatically into the ViewModel constructor.

Answer 4

I take a variety of different approaches depending on the situation. I've found that when it comes to getting this data linked, one size does not fit all.

For simple cases, I will have the ViewModel and the Model be the same thing. Obviously not that good for all cases, but sometimes there is just no need to go the extra mile to split the M from the VM. (Great for cases where you have, say, listbox items that have scant information)

Sometimes, especially when the model is a chunk of code you don't have access to (written by another developer) it is easy to subclass the model, and add all of your VM things (observable properties, etc.) on to it.

Lastly, I will use the approach that is mentioned by Souvik. Construct the VM with the model information that you want to use as a parameter, or allow it to be passed in otherwise. This is probably the most common approach for my larger and more complex Model / ViewModel relationships.