Is MVVM pointless?

Question

Is orthodox MVVM implementation pointless? I am creating a new application and I considered Windows Forms and WPF. I chose WPF because it's future-proof and offer lots of flexibility. There is less code and easier to make significant changes to your UI using XAML.

Since the choice for WPF is obvious, I figured that I may as well go all the way by using MVVM as my application architecture since it offers blendability, separation concerns and unit testability. Theoretically, it seems beautiful like the holy grail of UI programming. This brief adventure; however, has turned into a real headache. As expected in practice, I’m finding that I’ve traded one problem for another. I tend to be an obsessive programmer in that I want to do things the right way so that I can get the right results and possibly become a better programmer. The MVVM pattern just flunked my test on productivity and has just turned into a big yucky hack!

The clear case in point is adding support for a Modal dialog box. The correct way is to put up a dialog box and tie it to a view model. Getting this to work is difficult. In order to benefit from the MVVM pattern, you have to distribute code in several places throughout the layers of your application. You also have to use esoteric programming constructs like templates and lamba expressions. Stuff that makes you stare at the screen scratching your head. This makes maintenance and debugging a nightmare waiting to happen as I recently discovered. I had an about box working fine until I got an exception the second time I invoked it, saying that it couldn’t show the dialog box again once it is closed. I had to add an event handler for the close functionality to the dialog window, another one in the IDialogView implementation of it and finally another in the IDialogViewModel. I thought MVVM would save us from such extravagant hackery!

There are several folks out there with competing solutions to this problem and they are all hacks and don’t provide a clean, easily reusable, elegant solution. Most of the MVVM toolkits gloss over dialogs and when they do address them, they are just alert boxes that don’t require custom interfaces or view models.

I’m planning on giving up on the MVVM view pattern, at least its orthodox implementation of it. What do you think? Has it been worth the trouble for you if you had any? Am I just a incompetent programmer or does MVVM not what it's hyped up to be?

Answer 1

Sorry if my answer became a little lenghty, but don't blame me! Your question is lengthy as well. :P Firstly, MVVM is not pointless.

The clear case in point is adding support for a Modal dialog box. The correct way is to put up a dialog box and tie it to a view model. Getting this to work is difficult.

Yes, it truly is.
However, MVVM provides you a way for separating the UI's appearance from its logics. Noone forces you to use it everywhere, and noone is holding a gun against your forehead to make you create a separate ViewModel for everything.

Here is my solution for this particular example:
How the UI handles a certain input is none of the ViewModel's business. I would add code to the View's .xaml.cs file, which instantiates the dialog box and sets the same ViewModel instance (or something else, if needed) as its DataContext.

In order to benefit from the MVVM pattern, you have to distribute code in several places throughout the layers of your application. You also have to use esoteric programming constructs like templates and lamba expressions.

Well, you don't have to use it in several places. This is how I would solve it:

• Add the XAML to the View, and nothing in the .xaml.cs
• Write every app logic (except the stuff that would directly operate with UI elements) inside a ViewModel
• All the code that should be done by the UI but has nothing to do with business logic goes into the .xaml.cs files

I think that the purpose of MVVM is primarily to separate the logic of the application and the concrete UI, therefore enabling easy modifications (or complete replacement) of the UI.
I use the following principle: the View can know and assume anything it wants from the ViewModel, but the ViewModel can know NOTHING about the View.
WPF provides a nice binding model which you can use to achieve exactly that.

(BTW, templates and lambda expressions aren't esoteric if used right. But if you don't want to, don't use them.)

Stuff that makes you stare at the screen scratching your head.

Yeah, I know the feeling. Exactly what I was feeling when I first saw MVVM.

I had an about box working fine ...

Why would you put a ViewModel behind an about box? No point in that.

Most of the MVVM toolkits gloss over dialogs and when they do address them, they are just alert boxes that don’t require custom interfaces or view models.

Yes, because the very fact that a UI element is in the same window, or another window, or is orbitting Mars at the moment is none of the ViewModels' concern.
Separation of Concerns

EDIT:

Here's a very nice video the title of which is Build your own MVVM framework. It's worth watching.

Answer 2

I have seen the same issue with a lot MVVM implementations when it comes to (modal) dialogs. When I look at the participants of the MVVM Pattern then I have the feeling that something is missing to build a coherent application.

• View contains the specific GUI controls and defines the appearance of the user interface.
• ViewModel represents the state and behavior of the presentation.
• Model can be a business object from the domain layer or a service which provides the necessary data.

But missing is:

• Who creates the ViewModels?
• Who is responsible for the application workflow?
• Who mediates between ViewModels when they need to communicate with each other?

My approach is to introduce a (Use-Case) Controller which is responsible for the missing points. How this works can be seen at the WPF Application Framework (WAF) sample applications.

Answer 3

Getting this to work is difficult. In order to benefit from the MVVM pattern, you have to distribute code in several places throughout the layers of your application. You also have to use esoteric programming constructs like templates and lamba expressions.

For a commonplace modal dialog box? You are certainly doing something wrong there - MVVM implementation doesn't have to be that complex.

Considering you are new to both MVVM and WPF, it is likely you are using suboptimal solutions everywhere and unnecessarily complicate things - at least I did so when I first went WPF. Make sure that the problem is really MVVM and not your implementation before giving up.

MVVM, MVC, Document-View, etc. is an old family of patterns.. There are drawbacks, but no fatal flaws of the kind you describe.

Answer 4

I deal with the dialogs issue by cheating. My MainWindow implements an IWindowServices interface that exposes all of the application-specific dialogs. My other ViewModels can then import the services interface (I use MEF, but you could easily just pass the interface through constructors manually) and use it to accomplish what is necessary. For instance, here is what the interface looks like for a little utility application of mine:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

This puts all of the Dialog executions in one place and it can be easily stubbed out for unit testing. I follow the pattern that the client of the dialog has to create the appropriate ViewModel, which they can then configure as needed. The Execute call blocks and afterward the client can look at the contents of the ViewModel to see the Dialog results.

A more 'pure' MVVM design may be important for a large application, where you need cleaner insulation and more complex composition, but for small to medium sized apps, I think a practical approach, with appropriate services to expose required hooks, is quite sufficient.

Answer 5

No, it’s not pointless, but it is difficult to wrap your head around even though the pattern itself is ridiculously simple. There are tons of misinformation out there and various groups who battle over the proper way. I think with WPF and Silverlight you should use MVVM or you’ll be over coding and attempting to solve problems in a new model the “old” win forms methodology which just leads you into trouble. This is more the case in Silverlight since everything is required to be asynchronous (hacks around this are possible, but you should just pick another platform).

I’d suggest reading this article Simplifying the WPF TreeView by Using the ViewModel Pattern carefully to see how MVVM can be implemented well and allow you to change your win forms mentality to the new way of thinking in MVVM. In short when you want to get something done apply the logic to the ViewModel first not the View. You want to select an item? Change an icon? Don’t iterate over UI elements, just update the models properties and let data-binding do the nitty gritty.