"Advanced MVVM" Book Review
Justin Angel
Hi Folks,
I published a castigating review of Josh’s new “Advanced MVVM” book.
http://JustinAngel.net/AdvancedMvvmBookReview
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.)
Peter O'Hanlon
1) Data Binding
2) Commands
3) VisualStateManager. "
Peter O'Hanlon
Cory Plotts
Jeremiah Morrill
It was to illustrate MVVM and how you could apply that to any scenario ... even a simple game.
Evan Lang
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
Bill Kempf
really relevent list (the pattern, as you say, is about the separation
and not how you achieve the separation). You can go a long way using
Behaviors and Actions instead of commands. In fact, in the early days
we had to figure out how to bend commands to be MVVM friendly. It's
only recently, when DelegateCommand and it's variants have become so
prevalent, that we've started to associate commands with MVVM. In
fact, if I were to be totally objective, I'd even say that data
binding is irrelevant to the pattern. Martin Fowler talked about the
need to synrhonize state in his article about Presentation Model
(which I believe we all agree is the same pattern), and lamented that
this resulted in a lot of "boring and repetitive" code to write, and
even went on to say he was hoping this repetitive coding "will happen
some day with technologies like .NET's data binding."
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.
Colin Eberhardt
> BTW - MVVM is essentially about 1 thing, separating the View
> from the ViewModel from the Model; everything else is just implementation
> detail.
If that is the case, why is it called the MVVM pattern and not the
presentation model (PM) pattern as described by Martin Fowler?
http://martinfowler.com/eaaDev/PresentationModel.html
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.
Evan wrote:
"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:
http://www.codeproject.com/KB/smart/PMinAction.aspx
I have not read the article in detail - so can't vouch for its
quality!
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.
Regards,
Colin E.
Jeremiah Morrill
There, I fixed that one for you ;)
Colin Eberhardt
> 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.
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 ;-)
Regards.
Colin E.
Bill Kempf
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.
--
Peter O'Hanlon
Peter O'Hanlon
Colin Eberhardt
perhaps ;-)
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
the answer)
Regards,
Colin E.
Daniel Vaughan
do things.
On Mar 12, 9:09 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> Ahem.
>
> "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
> detail.
>
>
>
> 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.
>
> >http://JustinAngel.net/AdvancedMvvmBookReview<http://justinangel.net/AdvancedMvvmBookReview>
Bill Kempf
MVVM? They should! They should also call it crap, but that's a
different matter ;).
Glenn Block
Glenn Block
Evan Lang
Peter O'Hanlon
Peter O'Hanlon
Bill Kempf
back to Smalltalk and MVC. MVVM/Presentation Model is a variation on
this older pattern, along with other variations like Passive View. I'm
not sure if anyone in the game industry used MVVM prior to the
publication of the name or not, but if they didn't publish, they don't
get credit :). Gossman and Fowler get credit for independently
discovering/inventing this pattern in my book.
Glenn Block
Bill Kempf
before anyone even considered the fact that there were such things as
patterns. Just because one uses a pattern does not mean they get
credit for the patterns discovery. You have to realize a pattern
exists, and provide a name and description of the pattern. Without
that, it's just code, and not a pattern.
Bill Kempf
http://digitaltapestry.wordpress.com/
Laurent Bugnion, GalaSoft
presentation model. The rest are helpers that are there to help you build SL
and WPF apps. That includes commands, messaging, VSM, etc.
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
WPF/SL.
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
WPF.
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!!
;)
Cheers,
Laurent
-----Original Message-----
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
Laurent Bugnion, GalaSoft
working on the same stuff approximately at the same moment.
Cheers,
Laurent
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Bill Kempf
Sent: Friday, March 12, 2010 10:06 PM
To: wpf-di...@googlegroups.com
Laurent Bugnion, GalaSoft
Passive View is also interesting.
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.
Laurent
Justin Angel
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.
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Peter O'Hanlon
Sent: March-12-10 2:19 PM
To: wpf-di...@googlegroups.com
Michael D. Brown
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).
Michael D. Brown
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.
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Peter O'Hanlon
Sent: Friday, March 12, 2010 4:08 PM
To: wpf-di...@googlegroups.com
Josh Smith
Glenn Block
Agreed, for a long time we didn't want to use MVVM even over PresentationModel in p&p since they seemed one and he same. The way I reconciled was that MVVM is a derivative form of PresentationModel that implies a specific method of implementation (i.e. commanding and databinding). PresentationModel on the other hand is a very general pattern for simply wrapping a model and applying UI specific formatting and logic. If you take that definition you would say that MVVM is PresentationModel, but not every application of PM is necessarily MVVM.