Avoid MVVM/data binding for small windows?

Question

I've found view models to be very useful for splitting user interface and business logic code. However, I've also made the experience that for small, simple windows a view model class just adds a lot of additional code, effectively reducing maintainability instead of improving it.

Let me give you a simple, real-world example that I've had recently: A dialog window providing two (fixed-text) buttons and a customizable text block.

1. Using plain old x:Name-based code-behind programming technique, this is a matter of a few lines of code (set the text, handle the two button clicks by returning a value and closing the window) -- clean and simple.

2. Doing it the "recommended way", i.e., creating a view model class (implementing INotifyPropertyChanged or inheriting DependencyObject) and defining Commands requires an awful lot of code compared to the solution above (especially since there is no concise way to define "local variable + property + raise PropertyChanged" in VB) -- making the solution less readable and more error-prone.

So, currently I'm using the pragmatic approach of choosing between "plain old x:Name" and view model on a case-by-case basis. However, the wealth of blog/forum postings claiming that the view model should be used all the time makes me wonder whether I've overlooked something.

Did I overlook something?

Answer 1

I do the same.

Small dialogs and quick choice or information messages just get done in the simplest possible way. I try not to overcomplicate things with patterns that are unnecessary. The main application windows and anything larger is generally done with MVVM.

(So either you haven't missed anything, or I've missed the same thing.)

Answer 2

You can use data binding without defining a view model - and in most "small" windows there isn't mush logic - so you don't actually need change notification.

Just set DataContext = this and data-bind to properties of the window class.

Commands, on the other hand, don't have good simple version so I'll just use good old event handling.

(I also think that MVVM is overkill for a lot of not-so-small windows, but I'm obviously in the minority on that one)

Answer 3

I do something similar however in the situations where i just want a very small window that does something very basic i at least implement an interface and call it through a gateway so that i can call it in a testable way. Something like this :

//eg . in a viewmodel.cs or command.cs

var sometextIwantUserToEnter = UIServices.GetMeSomethingThatCan().GetText();

My window will implement IGetText and i do all the Window showing and result checking in the window itself in the GetText method. This keeps everything isolated in the window and i can assert that the service was called in my tests.

Hope that made sense.

Answer 4

I'm all for MVVM, but the window you're describing can be implemented once and then filled as needed when you want to open one. So the ViewModel might look like this:

public SmallDialogTask
{
    string Title { get; set; }
    string Text { get; set; }
    string AcceptButtonLabel { get; set; }
    string RejectButtonLabel { get; set; }

    Command AcceptCommand { get; }
    Command RejectCommand { get; }
}

Implement this once and use inheritance to configure the various instances where you need it. As you can see from my example, this allows you to encode much more semantics into your class.

See also DRY, my question about MVVM dialogs and -- just for reference -- my blog post about MVVM.