I was recently grabbing an auto generated TreeViewItem from a nested TreeView node in WPF, and I was using ItemContainerGenerator to get it in code behind. Then I thought to myself I’m certainly violating MVVM right now.
What are some other signs that someone is violating MVVM ?
1
You know when you are violating MVVM when:
-
The ViewModel is aware of the View. The ViewModel should never know or care if or what is sitting on top of it. It simply is. Sometimes, the ViewModel might need to generate events that should be handled on the View. When I was working with MVVM, we used the Mediator pattern to handle those cases.
-
The Model is aware of any other component. The layers build up. The View is aware of the ViewModel and the Model (because it databinds against it), the ViewModel is aware of the Model, and the Model is aware of nothing.
-
There is logic in the View that does anything other than things specific to the implementation of that View. All generic View state and logic should exist in the ViewModel, but sometimes implementation details are needed in the View. These should be sparing and never interested in anything other than View implementation-specific items.
There is one common pattern that runs throughout: separation of concerns. If any layer of MVVM is interested in anything other than its concern, there is a problem.
1
Not MVVM:
- ViewModel isn’t acting as an interface between model and View.
- ViewModel doesn’t provide data binding between View and model data.
- ViewModel doesn’t handle all UI actions by using command.
- State and logic aren’t stored in the Presenter.
- View isn’t isolated from the Model.
- View isn’t aware of the Presenter.
If your projet has at least one of the above, then you are violating MVVM.
Also, MVVM is a particular case of the PM (Presenter Model) where developers don’t need to implement the link between the View and the ViewModel. Since the PM is a more general scenario you cannot comply with MVVM without complying with PM basics.
Anytime your separation layers meld into each other, it’s a violation.
For Example
Having a declarative-only View makes it easier for non-programmer UI designers to change the UI. If you have code behind, then they will have to manage that code. The ViewModel doesn’t care who is above it, doesn’t care what View is consuming it. It is possible to have multiple views, for example a read-only and an edit View.
The ViewModel (VM) shouldn’t be talking to the backing data store, that should be the job of the model. So having your VM work with the database directly would be a violation, that’s the job of your Model.
My Opinion
Personally I make MVVM my own. There are the design principles I follow to the best of my ability but if the pattern becomes burdensome then I may violate it here or there and note it. It is supposed to make things easier on large projects, not harder.
However, with a lot of the MVVM frameworks there are for you to use now-a-days, it would be best to just pick one that fits and stick with it. These are designed to reduce the burden of the pattern and it should be an absolute best effort to not violate the pattern.
I think I violate the pattern because I use a WCF reference as my Model and talk to it from my ViewModel. I believe I’m supposed to actually create the Model manually and have that talk to WCF directly. I find this to be too much work.