Ok, I am being provocative here:
After attending LBugnion session "Das “Model-View-ViewModel” Entwurfsmuster" at the TechDays last week and now watching DNR-TV episode 161: Rocky Lhotka on the MVVM Pattern in CSLA .NET 3.8, I now dare to claim that:
The Model-View-ViewModel pattern is not a pattern!I have been confused for a long time.
Now I have come to the conclusion that I will stay with the classic presentation patterns and Fowlers discussion: MVC, MVP, Supervising Controller, Passive View, Presentation Model.
Those concepts are quite clear and provide a sufficient vocabulary to discuss architecture and design of the presentation layer of an application. There is nothing to M-V-VM that provides additional concepts that are not covered by the former patterns.
For Model-View-ViewModel I have just seen too many varying ideas, too many different concepts and too unclear explanations. So I can't accept it neither as an architectural- nor as a design-pattern.
The fact that in the Java world the notion of this pattern is nonexistent is also an indicator that this can't be a fundamental concept in software development (though technologies like xamlwpfsilverlight might legitimate the need for new patterns).
(disclaimer: I'm usually not pro-MS-frameworks - most of them are just blatant and not very good copies of already existing architectures, but WPF is one of the rare places where IMO they really created something new and useful)
ReplyDeletewow... I'd like to hear a bit more detail on what's lead you to this statement.
To me MVVM is at least as much of a pattern as the others you've mentioned - actually it's just the same as them, applied to the foundations on which WPF is built on, namely the concepts of DepecencyObject and co. And that's the very reason you won't find the pattern - as is - in other frameworks: you don't have the same foundation there. Still, the whole stuff is the good old MVC, where DO & INotify*Changed & Bindings are taking care of the observer/listener part so that you don't have to, but IMHO discarding them would be quite a step back.
Have a look at an article I wrote: "Simplified MVVM"
ReplyDeletehttp://www.codeproject.com/KB/silverlight/SilverlightMVVMVideoPlay.aspx
But I have to admit it's really just about a "ViewModel" and "View".
The "Model" really is not that important and if you just did whatever you wanted it would not make a difference.
MVVM is well defined -- it's just MVP using WPF/Silverlight data binding. Did someone claim otherwise?
ReplyDelete@sztupi
ReplyDeleteI just wanted to provoke a comment from you :-)
I remember that you explained MVVM in a very sensible way, and I saw that MVVM can actually be implemented in a productive way.
However I also remember that there were several people in the room and each had another idea what MVVM meant.
@Michael
Then why not call it PresentationModel with View? That pattern already existed...
@contextfree
Why invent the new name, why not call it MVP?
@contextfree & @John
Now, is it MVP or Presentation Model or both? That's exactly what I meant, there is no consensus ...
It's a pattern, but a bad pattern with a bad name.
ReplyDeleteBad:
Strict MVVM leads to a ViewModel violating Single responsible Principle. See http://www.planetgeek.ch/2009/08/30/why-mvvm-model-view-view-model-is-not-enough/ and http://www.planetgeek.ch/2009/10/18/agile-ui-development-in-net-table-of-contents/
Bad name:
Model View ViewModel, no logic in the order of the parts, View ViewModel Model or Model viewModel Model would clearly be better.