MVVM reloaded

I have just noticed a discussion on a small article at InfoQ:
Jonathan Allen lists a couple of signs that your MVVM design may have gone wrong. Here are the points briefly:

1. You have a model and a view-model with the same name.
2. You have a view and a view-model with the same name.
3. You have no code behind.
4. View-models are listening to property changed notifications

I don’t want to defend or argue about these points, rather it got me realized that I also had some concepts wrong at the start.

Graphics is a designer issue.
XAML separates the design and development processes completely. Isn’t this that would bring tremendous advantages after all. The dream is that Graphic Designers work on XAML and developers work on code. First of all, Graphic designers did not learn the new tool, language. The reason is that the concepts of graphic designs are so different from the concepts of application UI that designers can’t work properly in this environment. Layers for example are in every GD tool, yet they are missing as a concept from XAML, HTML etc… (You can workaround it, but that need dev skills 🙂 ).

No Code behind
UI related logic such as how often a blinky icon blinks or when the tutorial animation kicks in should go into the XAML code behind in my personal opinion. When I have a list box, and the items do animations depending on their type and some random timing, calculating when an animation should start and starting it should nicely fit into the code behind of the control. Obvoiusly if you need this behaviour more than one time you should create a proper Custom Control, but for just one instance it may be an overkill.
I did think at some point that the fingerprint of a good architecture is that there’s no code behind the XAML. Even though XAML is capable of much, UI logic is best described and maintained as usually logic is described and maintained, that is, in code, but not deeper than the XAML code behind. To put this very simply references to controls should only exist in XAML code behind. By delegating control references to ViewModels via commanding may be leaky nothing guarantees that the lifetime of the View and the ViewModel is the same, in reality the ViewModel is likely to hang around after the view is not visible on the screen.

Not to mention that the ViewModel should be View agnostic, so should never refer to a Button, or a Combobox.

View-ViewModel: 1-1
Usually a developer starts to create a UserControl (XControl) and with the same length of breath they create its ViewModel (XControlViewModel).

If we accept that the ViewModel should be View agnostic, the relationship should be at least *-1 and the name of the ViewModel should indicate that. So are we better of with the concept of EmployeeViewModel that reflects the Model type rather than the UI type.

No, not really. ViewModels should be more like facets of usage on the Model. I think it is a new conceptual layer that groups model elements and functional elements of related use cases together. I should really give you a good example at this point. So let’s take the example of the Model class Employee, you can have an EmployeeDetailViewModel where every aspects of the employees can be changed and viewed, and you could have an EmployeeSummaryViewModel where only main attributes can be changed, but also contains information of how this employee compares to other employees. I admit even in this scenario you probably end up with an EmployeeDetailControl, and an EmployeeSummaryControl, but the ViewModels should not be exclusive to them.


~ by baloghp on May 28, 2012.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: