Building an application using WPF, MVVM and Prism

Question

We are on our team, studying the possibility of using WPF with Prism.

Our current solution was built using Windows Forms, therefore there are a lot of factors that must be considered and studied before satisfactorily achieve the objectives of this architecture migration.

The MVVM pattern is one of the technologies that are among the new features that are tied to these factors. This pattern uses a quite different concept of that ones that our team currently knows.

We're reading and learning a lot about it, and we couldn't determine whether its use (purely) will be really productive for our purpose: We will create an application that will have a very large number of windows that will use the CRUD (Create, read, update and delete) model. E.g.: customer registration, registration of products, among others. We think the use of this pattern can cause rework during the Models definitions, which must be rewritten during the ViewModels definitions.

I wonder if anyone has any experience report or tip that can guide us regarding the use of these technologies.

Answer 1

If you are working with WPF, definitely use the MVVM design pattern. It makes life a lot simpler, and future maintenance easy.

Regarding your comment

We think the use of this pattern can cause rework during the Models definitions, which must be rewritten during the ViewModels definitions.

There are two ways to handle Models/ViewModels in MVVM. The "MVVM-purist" approach is to expose your Model's properties from the ViewModel, in which case yes you would be duplicating some code. A more practical approach is to expose the entire Model from the ViewModel. Both ways are acceptable, although I would recommend using the 2nd way unless you have a very large project with separate people/teams working on the Model and ViewModel layers.

MVVM Purist:

public class CustomerViewModel
{
    private Customer _customer;

    public string Name 
    {
        get
        {
            return _customer.Name;
        }
        set
        {
            if (value != _customer.Name)
            {
                _customer.Name = value;
                RaisePropertyChanged("Name");
            }
        }
    }
}

<TextBlock Text="{Binding Name}" />

More Practical approach:

public class CustomerViewModel
{
    private Customer _customer;

    public Customer Customer
    {
        get
        {
            return _customer;
        }
        set
        {
            if (value != _customer)
            {
                _customer= value;
                RaisePropertyChanged("Customer");
            }
        }
    }
}

<TextBlock Text="{Binding Customer.Name}" />

Regarding Prism, I think it's a great library. I prefer their NotificationObject and EventAggregator to my own, and like DelegateCommand once I got used to the fact it doesn't automatically raise it's CanExecuteChanged when the CanExecute parameter changes.

The only thing about Prism I don't really like is their RegionManager. I feel like it is letting the View control the application flow too much, and not the ViewModels. I also see it frequently misused for navigation, and quite often it turns into a mess. I still use it for defining my application layout (for example, MenuRegion, NavigationRegion, ContentRegion), however beyond that I use my ViewModel for all navigation needs.

So ultimately, I would say go for it! I love working with WPF, and I feel you shouldn't use WPF without the MVVM design pattern. Prism is also a great library to provide some of the missing functionality that I feel is needed in every MVVM application.