It’s a flying bat: ^^vv^^.
Sorry, I know that’s corny, but I still have to rail a bit against the name.
Anyway, Model-View-ViewModel, or MVVM for the TLA (FLAB?) loving folks, or just ViewModel for those that don’t like tongue twisters but want to pay homage to the “original” name, or Presentation Model for those Java folks, or even MVPoo for Drs. and folks fed up with the various names, is a UI design pattern. The pattern separates the display (View) from the presentation state and logic (ViewModel) and the business data and logic (Model). That’s it. Nothing more, nothing less.
So, why am I blogging about this if that’s all I have to say about what MVVM is? Because lately I’ve been reading a lot of claims about MVVM that lose track of what MVVM is, making claims that are not strictly accurate.
Let me start with one that came up in the WPF Disciples group recently. Justin Angel posted an review of Josh Smith’s Advanced MVVM book. In his review he talked about how MVVM was “essentially about these 3 things:”
1) Data Binding
2) Commands
3) VisualStateManager
See, that one rankled several folks. When MVVM was “discovered” by John Gossman, the VisualStateManager didn’t even exist. Also in those early days we had problems bending Commands to MVVM usage, as this was before RelayCommand, DelegateCommand et. al. Heck, even Data Binding isn’t an essential part, as Martin Fowler lamented about having to write boring and repetitive code to synchronize state, and even said he hoped that some day something like .NET data binding could be used. See, all of these things are implementation details, and patterns are not about implementation details. They’re about, wait for it, the pattern (see, it’s not just a clever name).
Another one that came up recently on the Disciples list was a discussion around a blog post someone had run across. This was a short post, but it generated a lot of discussion about various things. I won’t go into the details, because it was a private discussion. The blog post made two mistakes that are relevant here, though, so I’ll discuss them. The first was a similar mistake in trying to tie MVVM to implementation details like Commands and Dependency Injection. I’ve already pointed out how that’s wrong, so let’s move on to the second mistake. He stated that when following MVVM the goal was to have no code in the codebehind. This just isn’t true. Having a clean codebehind is a goal I have, since it helps with the developer/designer separation, and this goal is possible because of MVVM (and other patterns and techniques), but this isn’t a goal of MVVM. You can, and I some times do, put code in the codebehind while following a strict MVVM pattern.
Then there’s another topic that also came up in the Disciples list that’s a particular bee in my bonnet. Several folks tried to make the claim that in MVVM the ViewModel should never have a reference to the View. That’s just hogwash. Nothing in the pattern states this. What is true is that you should avoid creating a hard coupling between the ViewModel and the View, but that’s just good software architecture and has nothing at all to do with the MVVM pattern. What’s funny is these same folks have no issue with creating hard coupling between the ViewModel and the Model, which causes the exact same issues as hard coupling between the ViewModel and the View and so is just as ill advised. But there’s not a darn thing wrong with having weaker coupling, and there’s lots of reasons why you might want to have the coupling. For instance, imagine your loose coupling entailed an IView interface that exposed Show and Hide/Close methods to allow the ViewModel to control the visibility/existence of the View. Do you see anything wrong with this sort of coupling? I sure don’t. More important, do you see anything in the pattern description that discusses this? I sure don’t.
Another claim made several times by many people is that MVVM is a refinement of Presentation Model using WPF concepts like Data Binding and Commands (this argument usually being made to justify keeping the longer and more awkward name of the pattern). See, this is just a variation on the other mistakes I’ve discussed. If this statement were strictly true, then MVVM wouldn’t be a pattern, it would be a framework based on the Presentation Model pattern. Remember, patterns aren’t about how things are implemented, they are strictly about the, ahem, pattern.
Digital Tapestry 