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 
That last claim was me so I can speak on it. MVVM is a pattern, however you can have derived patterns. I spoke with Martin Fowler about this and he agreed. Presentation Model is completely generic, it implies no constraints whatsoever OTHER than the fact that it is a UI-centric model which can have UI-specific semantics, for example exposing an actual color. You can read about this in POEAA.
As far as MVVM, it is used in a very specific sense rather than a generic sense. It implies that the View talks to the model through binding for both data and action. In previous binding frameworks like traditional winforms binding, you could not bind actions only data. It is the evolution of the binding engines that has enabled a richer form of communication to occur.
On the issue of coupling, I am one of those who says vehemently that the ViewModel having a connection to the view through an interface does not invalidate the pattern. However, I also disagree with your follow up statement. The reason for having the ViewModel talk to the view through an interface is to promote better testability. In most cases with MVVM you don’t need the connection, the places where I think it’s valuable are if you are going with a view model first style where an IoC creates the VM and you want to let it create the View as well through injection.
On the reverse side though there is no such need for decoupling relating to the testability aspect. You don’t test the view. If you have to test the view that’s a code smell that your View is not observing proper separation of concerns.
Now there are several folks who want to decouple the View from the ViewModel in order to allow maxium reuse of ViewModels across different views. In many cases I say to this YAGNI, but there are cases where it makes sense.
Thanks
Glenn
You were far from the only one to make the claim about MVVM being a refinement, so this isn’t directed at you. This reply does a much better job of trying to justify this claim then any I’ve seen made by anyone, but I still have to respectfully disagree. If data binding the state doesn’t lead to a refinement of the pattern, which Martin Fowler clearly doesn’t think it does, then “data binding” the “behavior” doesn’t either. This is an implementation detail, and in no way alters the pattern.
On the issue of coupling, I’m not sure what follow up statement you’re referring to? Hard coupling the VM to the V not violating the pattern? I was taking an extremist stand to make a point. First, the decoupling is about much more than testing, and it’s a general design principle and not something specific to the pattern. I’ll grant that both the original posting on MVVM and Fowler’s posting on PM both discuss the pattern in terms of using loose coupling. Maybe loose coupling should be considered a part of the pattern, though defining loose coupling can be tricky. I can provide the FooViewModel with a reference to the FooView and the FooViewModel can still be testable if that’s your only requirement for loose coupling, which was really the point I was trying to make. The pattern is really about the separation, and not about whether or not there’s any coupling.
As for reversing things, I have to disagree. You’re correct, you don’t need to test the V, but having the VM coupled to the V is irrelevant to that subject. What’s relevant is whether or not this coupling makes the VM untestable. When having a hard reference to the M, you’re going to have the same testing issues as you’d have if you had a hard reference to the V. In both cases the reference has to either not exist, or be weak in nature in order to test the VM.
As for decoupling the V from the VM to maximize reuse… weak coupling does this as easily as no coupling does. I’ve always maintained some sort of weak reference to the V in my VM, and I’ve never been prevented from using the VM with multiple Vs in the application. I must say, however, that like you I find this more of an academic quality, as I VERY rarely find a use for this.
Just to add to this, I was originally very much against the new name. When we were building Prism I used to call it “The Pattycake pattern” in derogatory fashion. We had several discussions on whether or not it actually was something new or if it was just PM. Over time though and seeing how it is practiced and used in conversation, it became apparent that when people say MVVM they mean something with a specific set of constraints.
Not so with the simple word ViewModel which exists in MVC and which has a different meaning which is simply a pure data container 🙂
Thanks Bill
Reading your follow up I think we’re saying more of the same thing than different, but somehow we’re shooting above / below each other 🙂
I’ll summarize in saying that MVVM is not black and white. It’s not like there’s a simple line and if you cross it, you are NOT MVVM. This means for example you shouldn’t have an absolute FXCop rule called “NoCodeInThCodeBehind”, though you could have a “NoBusinessLogicInTheCodeBehind” 🙂
As far as the MVVM “pattern”
Patterns are a blue-print for how a particular problem is solved. In the case of MVVM there are a recurring set of constraints / differences that are implied when you say “I am implementing MVVM”. Those differentiate it simply from saying “I am implementing PresentationModel”. In particular I am talking about leveraging the databinding/templating capabilities of the UI XAML stack.
It is these differences that let you look at an implementation and say “Oh, that’s more like MVP not MVVM” for eample.
When I suggest folks use “MVVM” ( or see others doing), I think we’re saying there’s a specific form of PresentationModel that meshes really well with the underlying platform. It involves players like binding, templating, commanding etc, which is why it has it’s own specific name.
If I try to apply the same patterns in say WinForms, it won’t work. Why? Because the binding engine is limited to pure data values bound to controls.
Anyway guess this is beating a dead horse.
Regards
Glenn
Yeah, we mostly agree, except with that “MVVM is a refinement” bit :). Again, in this very reply you talk about “leveraging the databinding” as an example of such refinement, while Fowler’s description of PM clearly states that databinding would be a good fit to the pattern. All of the “refinements” you mention are simply implementation details, not changes to the pattern.
I’ve beat that dead horse enough. On this one topic I guess we’ll have to agree to disagree. Lucky it’s an academic and useless argument when it comes to folowing the pattern, what ever name you want to give it (can we settle on MVPoo now?).
Can I add my rant? ‘MVVM Like’ design has greats benefits. But, isn’t this like “three tier architecture” ? Could you make a FxCop rule to validate it? If a Programmers has 3 tiers but has some business rules in his stored procedures should we just say “what he has is crap, ignore that guy, he doesn’t get it”.
I hope we can all come up with a new name “VM”. It would mean “you have a View and a View Model, period”.
Then we would all agree that anything that has a View and a View Model IS “VM”.
Then we would see a bunch of people blogging about it and using MEF with it, and doing it 100 different ways, and Microsoft would be happy because we would still be using Visual Studio and Expression Blend to do it 🙂
I hope we can be “inclusive” to encourage scientific debate an forward progress.
I’m not certain I fully understand your post. What is “MVVM Like”?
Tiered architectures are about separation of locality. In MVVM and other presentational architectures you can put the various components in separate tiers, but that’s not what the patterns are about. When you do that, you’re combining multiple patterns. I’m not saying that this is a bad idea. Actually, it’s often a very good idea. But when discussing the individual patterns it’s usually a good idea not to muddy the waters with discussion of other patterns. If you’re going to discuss a particular architecture instead of the individual pattern, then mixing would be a good thing… but you should be careful to point out that two (or more) patterns are being used. Did I not understand the reason why you brought up tiered architectures in this discussion?
VM is the name a lot of people are moving to, but this name is still for the same pattern, and the Model hasn’t gone anywhere. Are you really suggesting there should be a pattern that doesn’t include the Model? To what end? I don’t see it making anything clearer.
I hope I’m inclusive and open to debate and forward progress. Variations on the pattern are great, and should be encouraged. What shouldn’t be encouraged is sloppy statements (and I’m often guilty here myself) about terminology and/or patterns that are flatly wrong. I think I explained this fairly well in this post. In fact, a lot of the things I discussed here should encourage more open discussion and variations on the pattern. For example, people that claim that the VM should never reference the V are not only stating something that the pattern doesn’t, they’re also shutting down many variations on the implementation of the pattern. We can debate whether or not it’s a good thing to do so, but only because the pattern doesn’t exclude this variation.
I apologize if I accused you to not being open, That is incorrect, I was referring to others.
I also should have said “It’s ‘VM’ if is has a View and a View Model ANYWHERE in the design”.
So you could have a Model, or not. You can have some code behind, or not.
Then we can all discuss our VM MEF design and we wont spend time accusing others of ‘not being something’. I understand WHY people say that, they want to reduce confusion that makes it hard for people to learn MVVM.
But, it does strike fear in people because they are ridiculed. A guy just posted a article on MVVM that even I feel is WAY off (there is a laughable amount of irony in that last statement :)).
I doubt that the guy will post again. So a person can bog about new ideas but can’t use the letters “MVVM” or they will be ridiculed? But, HOW can they convey the message that this is what they are referring to?