Implementing the pattern MVVM correctly

Question

I am trying to implement the MVVM pattern but I am running into some trouble.

The whole application can be seen as a wizard. You have to select an item within Dialog A to see Dialog B, which depends on your selection. Dialog C is independent of the other selections but has to execute some business logic, which is dependent of the previous selections.

What I tried to do was to implement a BaseViewModel to save references to those selections. The BaseViewModel has a reference to the real model, which retrieves data from a DB and stores them as Properties.

The first issue I see is that the BaseViewModel acts like a 'Facade' to the model since it offers access to the models properties to the view.

The second issue is that I do somehow use the same BaseViewModel (and the same reference) for nearly every view. In my opinion this just does not feel right. It is like I am using a usual MVC pattern by adding complexity with an unnecessary (?) ViewModel.

An additional problem is, that the ViewModel of Dialog B is dependent of the selection of Dialog A. Do I have to implement a Property, which retrieves the data elements for the model whenever it is accessed?

Do you guys have any comments on the system?

Thanks in advance.

Answer 1

First let my say that there is no 'correct' answer in an absolute sense. It all depends on how you tackle the problem, on your skills, and the opinions of the guys that you ask.

That said:

• I think that your first issue isn't one at all. Being a facade around the model is exactly what the VM in MVVM or the C in MVC is meant to be.
• Regarding your second issue: if you have a wizard-like structure, then it makes sense to consider the dialogs A, B, and C as different parts of one big view. In that case, it also makes sense to back it with one single data object, whether you call it ViewModel or Controller or whatever else (as long as you don't access your business data directly from within the UI).

Always keep in mind that these pattern are not there to follow them religiously, but to make sensible use of them to cope with real world problems. So first model your problem (i.e. the business case), then design the UI, and only then decide about the data structures and Design Patterns.

So the decision for MVVM (or MVC or whatever you will call it in the end) come last...

Answer 2

I think I would consider doing away with your BaseViewModel and separating out your functionality into individual VMs for each piece of functionality (1 View: 1 ViewModel). You can then pass the necessary data between each VM as required using something like the MVVM Light Messenger: Proper way of using MVVM Light Messenger .

Answer 3

May be a bit late to the party, but...

You should separate your business logic from ViewModels. ViewModels should actually just contain presentation logic.

I'd add a IConfigurationService and it's appropriate ConfigurationService implementation. Register it as a "singleton" (exact name depends on your IoC container terminology, i.e. ContainerControlledLifetimeManager in Unity IoC container) and have your ViewModels accept a IConfigurationService in it's constructor.

public WizardPage1ViewModel : ViewModel 
{
    private IConfigurationService configService;

    public WizardPage1ViewModel(IConfigurationService configService) 
    {
        this.configService = configService;
    }

    public string InstallationPath 
    {
        get { return this.configService.InstallationPath; }
        set 
        {
            if(path!=value) 
            {
                this.configService.InstallationPath = value;

                OnPropertyChanged("InstallationPath");
            }
        }
    }
}

And in your final ViewModel you just read it from that service. No messaging required. You need Messaging/Event Aggregators only when the view don't know about the receiver of the messages/events.

ViewModels should really only be concerned about Presentation Logic (taking input from UI, react to buttons, format values to be presented in the View, i.e. i18n)