Some MVVM Badness

I must say, I really like the MVVM pattern for doing both Silverlight and WPF development. I have been using it for quite some time now, with and without a standard framework. And although I really like the pattern, I have also seen some bad code pop-up in applications that are more like anti-MVVM. The reason for this is that the responsibilities of each part of the MVVM pattern get mixed up. People seem to think that once their class has the 'ViewModel' extension it actually behaves like a viewmodel, which is not always the case.

For starters, I have seen people use MVVM without the first M. That is, people tend to do MVVM without a model and just put everything in their viewmodel, even their model data. It pops up like private data members in the viewmodel, where they actually should use a model. The temptation for doing this can be quite big, since often you have to put propertychanged notifications in your viewmodel. It just seems that much easier to skip the model for this. The temptation seems to be biggest in applications where there is no real back-end, like a service, that needs to be called, that hands you off something model-ish.

Another sin in MVVM applications is the over-use of the commands in a viewmodel. They are there as a hook for your view to tell the viewmodel to 'do something' or that 'something needs to be processed'. This doesn't mean that all of the logic for the something that needs to be done, has to be put in the viewmodel. It is ok for the viewmodel to ask some other component to handle the details of the something that needs to be done. For this, keep the rule of single responsibility in mind. The moment your viewmodel starts to do more than what it's supposed to do, you probably need to refactor out some of the logic (maybe hand it of to the model or to some other component).

Your viewmodel should only have the logic for bridging between your view and your model. It is there to present the data of the model in such a way so that it makes sense to the view. And it also contains commands so that the view can interact with the model. And that is all it should do. This also implies that the model can be (even has to be) more than just a POCO or DTO, it can contain logic if it needs to. This is often a misconception in MVVM, where the model is seen as just a class that contains data. But this is often not the case. Often, the model is a back-end, which contains business logic and which hands you off POCO or DTO classes. Often it is more than just one model class, it can be a whole bunch of classes, all interacting to provide your viewmodel with services.

A last offense can be found in the view. It is still ok to put logic in the xaml.cs file, but make sure you limit this to view-specific logic. That is, for instance, the logic that is needed for a certain animation to display properly. And that's all. All of the other logic should be in your viewmodel or should be delegated from your viewmodel to other components. So don't start putting state specific logic in the code behind of the view. This means that, if you have animation specific code in your code behind, the actual check 'IsAnimating' should be in your viewmodel.

That's the end of my MVVM pattern rant. I really really like this pattern, but just keep in mind that it is not because you use a certain pattern, your code keeps to it. Keep the different responsibilities of each part of the pattern in mind, so you don't accidentally mix them up.