I published a castigating review of Josh’s new “Advanced MVVM” book.
Feel free to leave your feedback in the comments or on this list.
If there’s anything I haven’t taken into account, I’d love to change the blog post and make it more even-handed.
-- Justin Angel
(Feeling like the furry green guy who stole the winter festival.)
It was to illustrate MVVM and how you could apply that to any scenario ... even a simple game.
As nothing more than a pattern, it’d be instructive to point out that MVVM could be implemented through LISP and INI files.
It would surely be the cause of a great many suicides, but it could be done…
Seriously though, I think a blog post about how one might implement the tenets of MVVM in non-XAML, non-C# based environments might be highly instructive out there to the apparently confused masses who think MVVM is an API. I’m no MVVM guru so I’d invite any of you guys to feel free to jump on that. J
In WPF, today, it's common to use data binding and commands to
implement the MVVM pattern. In SL maybe it's also common to utilize
the VSM, though my lack of exposure to it leads me to wonder if that
doesn't to tightly couple the V and VM? But for an article that's
using WPF, I wouldn't expect to see any VSM code.
I've not read the Josh's book yet, but that part of the review stuck
out to me and made me question the validity of the rest of the review.
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
If that is the case, why is it called the MVVM pattern and not the
presentation model (PM) pattern as described by Martin Fowler?
I have seen MVVM described as a realization or refinement of the PM
pattern in a number of places and I would agree. It is a specific way
of implementing the PM pattern that happens to work very well in WPF /
Siverlight. It also incorporates some technology specific concepts
like developer / designer workflow.
"Seriously though, I think a blog post about how one might implement
the tenets of MVVM in non-XAML, non-C# based environments might be
highly instructive out there to the apparently confused masses who
think MVVM is an API. I'm no MVVM guru so I'd invite any of you guys
to feel free to jump on that. :) "
I recall seeing an article demonstrating how a PM can be shared across
WPF, WinForms & ASP.NET:
I have not read the article in detail - so can't vouch for its
I have also used PM / MVVM in the design of complex WinForms controls.
However, when the MVVM pattern is employed in WPF it is to provide
look-less / blendable controls. For WinForms our reason for using the
pattern was for testability.
The VSM concept uses attached properties to assign states to controls
and define transitions between states. I am not sure it has much to do
with MVVM. I am pretty sure that unless your VM is a Control it canot
have a visual state, in which case the VSM sits entirely within the V.
For this reason, I don't think you can castigate Josh for leaving it
out of the book.
However, if MVVM is more than just the Presentation Model, and is
about the whole process of WPF / Silverlight development, which
includes design, then the VSM is probably worth a mention.
Incidentally, in a LOB application you probably have much less need
for VSM & Blend anyhow ;-)
Because MVVM was the name given to the pattern by John Gossman when he
independently discovered it, while Presentation Model was the name
Martin Fowler gave it when he independently discovered it. It *IS THE
SAME PATTERN*. The claim that MVVM is a refinement using WPF
techniques is just a justification for sticking to the longer name
made after the fact. I've hated that distinction, because it leads
directly to claims like this one here. The pattern is NOT about data
binding, commanding, VSM, event aggregator, IoC, service location,
Behaviors, Triggers, Actions or any of the dozens of other techniques,
classes and patterns we use to realize the MVVM pattern.
However, could you implement the MVVM pattern in WPF in such a way as
to ruin the designer workflow? In this instance would people still
call it MVVM?
(By the way, this is not meant as a rhetorical question, not having
owrked with Blend or the arty types I expect use it, I am not sure of
On Mar 12, 9:09 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> "MVVM is essentially about these 3 things:
> 1) *Data Binding*
> 2) *Commands*
> 3) *VisualStateManager*. "
> That's a particular Silverlight conceit. VSM is a poor second cousin in WPF.
> Having read Josh's book, I think that it's beholden on me to leap to his
> defence here, you should have mentioned that this is effectively part 2.
> This book is the follow up to Josh's highly successful MVVM article in the
> MSDN magazine. BTW - MVVM is essentially about 1 thing, separating the View
> from the ViewModel from the Model; everything else is just implementation
> On Fri, Mar 12, 2010 at 6:56 PM, Justin Angel <J...@justinangel.net> wrote:
> > Hi Folks,
> > I published a castigating review of Josh’s new “Advanced MVVM” book.
Regarding databindings, the way I see it is that presentation model is an
extension of the Passive View pattern where the view is a bit more active
(since it is notifying the viewmodel when something changes). Passive view
is great because it doesn't need to be unit tested (since it is passive),
but presentation model is great in frameworks that have extensive data
binding like WPF and SL. Thus, presentation model (aka) works great in
You are mistaken that only a control can have a state. VSM can be applied to
any framework element. If you use VSM in a panel (such a grid) however, you
need to trigger the state change yourself. Typically we do this using a
Blend behavior such as the GoToStateBehavior (reacts to an event) or the
DataStateBehavior (reacts to a property change). However I would typically
not do that in WPF, because of the need to use a Blend behavior which
requires Sys.Win.Interactivity.dll. Instead I would prefer Data trigger in
Finally, you should see the last LOB application I worked on at
IdentityMine. This thing's design was so complex (and beautiful) that I
couldn't have done it without Blend. LOB != ugly!!
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Colin Eberhardt
Sent: Friday, March 12, 2010 10:02 PM
To: WPF Disciples
Subject: [WPF Disciples] Re: "Advanced MVVM" Book Review
On Behalf Of Bill Kempf
Sent: Friday, March 12, 2010 10:06 PM
In fact, if I am not mistaken, Fowler came to the Presentation Model idea
through the passive view pattern. Presentation Model, as I wrote just
before, is a variation of passive view where the view is a bit more active.
This works great in WPF and SL, because the active part is played by the
databinding system, which is included in the framework, and thus does not
need to be unit tested. So you have the advantage of passive view (no unit
test of the view) and the flexibility of a moderately active view.
LOL. Sorry about that, I’m moving to San Francisco on Monday and I’m busy running errands.
I’ll respond to the disputed pointes soon.
Plain and simple…I haven’t read Josh’s book yet because I’ve got a huge deadline looming. But even without reading Josh’s book, I can refute your arguments.
1. VSM didn’t exist when the MVVM pattern was created so saying that VSM is a pillar of MVVM is ludicrous.
2. When I was planning to write an article on MVVM, my initial thought was to take an existing game (Charles Petzold’s Contagion sample) and apply MVVM to it
3. Saying that because there was only one example of the command pattern in the book is a bad thing is faulty logic. The book is meant to provide examples of how the pieces fit together. Once he’s shown it one time, what’s the point of repeating himself?
4. When I demonstrated the Azure Service Bus, I used a very refined and refactored sample. The audience spent more time trying to figure out what I was doing because I was using patterns that they hadn’t seen before that the point of “Hey it’s a simple WCF service call to do this” was lost. So yes the code isn’t using “best practices” but it is approachable to all levels and it doesn’t get in the way of Josh’s message regarding MVVM
5. First you argue that his code is too simple and needs to be refactored, then you say that it’s too complex and mired in the details of the game…please make up your mind.
6. Using DataTriggers against a bound property to change a control is a very advanced MVVM technique. VSM may have replaced the need for this, but that does not invalidate it as a valid approach.
I’m not sure if your “review” was just being contrarian or what. But I find it funny that I found more flaws in your discussion of the book than you found in the book. Even worse you list other resources on MVVM and don’t mention the ONLY article on the topic published in MSDN Magazine (by Josh Smith).
Yeah we’ve had this discussion before it’s tragic that there is a “perceived” difference in the pattern because of the two different names. I’ve applied VM to WPF, Webforms (using a nice trick with ExpressionBuilders to create a more suitable binding syntax –BTW I’ve been BEGGING Rob to consider adding a similar api to WPF, think markup extensions that get evaluated once and compiled WITH the XAML), and Winforms. MVVM, ViewModel, PresentationModel all the same thing…I wish Martin would update his article to give some “authority” to it.