"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]

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.

--
Peter O'Hanlon

[Cory Plotts]

I totally agree with Peter ... my reaction on reading that the VSM was one of the main tenets of MVVM .... was "What? Are you serious?"

I've only read halfway through Advanced MVVM but have thoroughly enjoyed it so far ... and think it offers a lot to the community in terms of what MVVM is about.

And to your point that it isn't a good gaming tutorial ... I don't think that was Josh's intent at all. It was to illustrate MVVM and how you could apply that to any scenario ... even a simple game.

[Jeremiah Morrill]

 It was to illustrate MVVM and how you could apply that to any scenario ... even a simple game.

I was just about to write something similar when your email came in.

-Jer 

[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

[Peter O'Hanlon]

Now that's just sick.

--
Peter O'Hanlon

[Bill Kempf]

Yeah, even Commands could be questionable in such an arbitrary and not
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]

Peter wrote:
> 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]

"you just can’t have a conversation [with Justin Angel] about MVVM without these 3 core concepts."

There, I fixed that one for you ;)

-Jer

[Colin Eberhardt]

> 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.

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]

Arghhhhh!!!!

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]

Well said, and much more eloquently put than I could.

--
Peter O'Hanlon

[Colin Eberhardt]

I had not realized it was a parallel discovery (or invention
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]

I enjoyed the book. Thought it was solid. Josh gets it, and it's how I
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]

Yes, you can. Would I? Absolutely not! Would people still call it
MVVM? They should! They should also call it crap, but that's a
different matter ;).

[Glenn Block]

MVVM as a pattern has NOTHNG to do with VSM. VSM is an implementation detail. MVVM is about one thing, UI decoupling. Commands and Databinding are the common way to achieve that. VSM might make sense, but I would hardly call it integral.

[Glenn Block]

I just replied on the blog and stated my issues with your review.

[Evan Lang]

If we're concerned with whom deserves credit for the invention of MVVM, it probably belongs to someone in the video game industry, though I couldn't begin to guess who. I dunno if any of them ever put a name to it, but separating code concerns from designer concerns WRT user interfaces is something they've been doing for a long, long time.

[Peter O'Hanlon]

I see the way that this works now. Every now and again, one of us has to post something really controversial and then sit back and watch while the flames get higher. My turn...

 

Josh. Bach sucks. (Now I know that Josh is big enough to let critique of his book slide, but dissing the JSB will arouse him to levels of apoplexy not seen since somebody stopped Karl from taking a computer on holiday; I happen to know that Karl went Ninja on the travel agents ass that day).

--
Peter O'Hanlon

[Bill Kempf]

If it's just separation of code concerns from designer concerns we go
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]

I like Fowler, but undue credit goes his way. He didn't name anything. He compiled the pattern that others were already using.

[Bill Kempf]

Yeah, well, you know, we were all following the GoF patterns long
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]

I just blogged on this topic (MVVM misunderstandings, not the review).

http://digitaltapestry.wordpress.com/

[Laurent Bugnion, GalaSoft]

The way I explain it in my MIX talk (on Monday) is that MVVM is just
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]

Agreed. This was confirmed to me by John Gossman himself. They were just
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]

There are many separation patterns. MVC is the best known probably, but
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]

Thanks for the book review, Justin. 

Josh

On Fri, Mar 12, 2010 at 10:56 AM, Justin Angel <J...@justinangel.net> wrote:

[Glenn Block]

Laurent

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.

 

Thanks

Glenn

[Glenn Block]

Having a review is great. Saying "Don't buy this book" personally I think goes over the line from personal preference.....

On Fri, Mar 12, 2010 at 4:45 PM, Josh Smith <flappl...@gmail.com> wrote:

[Josh Smith]

Yeah, I agree, but what's the point in arguing with someone over it?  I can't force him to edit his own blog, so whatever...

[Josh Smith]

And, plus, by making such a big stink about how awful my book supposedly is, I assume it will make the more skeptical of his readers intrigued about the book.  Who knows, it might even lead to some sales! :)

[Glenn Block]

It's all about sales eh :-)

[Josh Smith]

I wouldn't say it's all about the sales, but mostly. ;)

Other than the extra income, this book is something I'm proud of.  It's easy to criticize someone else's work on the Web, so I am used to receiving all types of crap from people about my publications.  I know that I'm happy with the book, and think it's a worthwhile achievement.  If someone else gets off by bashing my work in public, that's their prerogative.

Josh

[Glenn Block]

Well you definitely know by the feedback that you are pushing the right buttons :-)

[Josh Smith]

Or the wrong buttons, depending on who you ask! :)

[Josh Smith]

Hey Justin,

I left a comment on your blog post, but after refreshing the page, my comment disappeared.  Might be a bug in your blog...

[Josh Smith]

Justin -- I just left another comment on your blog post.  In case it gets lost too, here's the text, so maybe you could add it in:

Hey Justin,

I'm sorry that you didn't enjoy my book.  It sounds like you and I have very different opinions on what MVVM is and what constitutes a good MVVM book.  I'm happy with how my book turned out, and I've received a lot of positive feedback from folks who have read it.  I hope your review proves useful to others who think along similar lines to you, and prevents them from buying a book they might not enjoy.

Thanks,

Josh

[Glenn Block]

Just responded on your post, but continuing here :-)

 

My point is MVVM is a derivative pattern. Patterns can be derived. I absolutely believe it is a derivative from of PresentationModel. However it's a form that does imply attachment to a particular technology in particular the notion of databinding for actions and data. Your right, that using commands is not absolutely necessary, though has been until recently the most common way. The key about binding handling actions (let's consider behaviors a form of binding for now) is that it removes the need for the View to hold a direct connection unlike MVP where the View must hold a connection to the presenter. For example if you implement Supervising Controller traditionally, the View must hold a reference to the presenter in order to handle UI gestures while the rest goes through binding. In MVVM because of the richness of the binding engine this reference goes away as everything can be expressed declaratively.

 

PresentaitonModel in it's purest form implies no such constraints. It doesn't require binding to be present at all. It simple means I have a model that is crafted specifically for presentation. Like MVP the view could hold a reference to it, pulling and passing it's data to it, and delegating to it for it's actions. The key thing about PM is that the view renders directly based on the PM and does not format / manipulate the underlying model.

 

Nice post btw.

Glenn

On Fri, Mar 12, 2010 at 12:40 PM, Bill Kempf <wek...@gmail.com> wrote:

Yeah, even Commands could be questionable in such an arbitrary and not
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.

On Fri, Mar 12, 2010 at 3:09 PM, Peter O'Hanlon <pete.o...@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
>>
>>
>>
>> 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
>

[Glenn Block]

Yes and he didn't give the name to the pattern either.

On Mar 12, 2:25 pm, Bill Kempf <weke...@gmail.com> wrote:
> Yeah, well, you know, we were all following the GoF patterns long
> 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.
>
>
>
>
>
> On Fri, Mar 12, 2010 at 5:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> > I like Fowler, but undue credit goes his way. He didn't name anything. He
> > compiled the pattern that others were already using.
>

> > On Fri, Mar 12, 2010 at 2:20 PM, Bill Kempf <weke...@gmail.com> wrote:
>
> >> If it's just separation of code concerns from designer concerns we go
> >> 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.
>

> >> On Fri, Mar 12, 2010 at 5:16 PM, Evan Lang <evan.l...@identitymine.com>

> War is peace. Freedom is slavery.  Bugs are features.- Hide quoted text -
>
> - Show quoted text -

[Glenn Block]

They all came from or were directly inspired by Smalltalk.
Seriously...including MVVM if you talk to John. He told me on several
occasions the folks who floated the idea at MS came out of smalltalk.

Regardless we spend way too much energy focusing on who coined it
first!

On Mar 12, 2:25 pm, Bill Kempf <weke...@gmail.com> wrote:
> Yeah, well, you know, we were all following the GoF patterns long
> 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.
>
>
>
>
>
> On Fri, Mar 12, 2010 at 5:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> > I like Fowler, but undue credit goes his way. He didn't name anything. He
> > compiled the pattern that others were already using.
>

> > On Fri, Mar 12, 2010 at 2:20 PM, Bill Kempf <weke...@gmail.com> wrote:
>
> >> If it's just separation of code concerns from designer concerns we go
> >> 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.
>

> >> On Fri, Mar 12, 2010 at 5:16 PM, Evan Lang <evan.l...@identitymine.com>

[John Gossman]

I like Gossman, but undue credit goes his way.  Other folks were using MVVM terminology inside Microsoft before WPF.  The WPF and Sparkle teams were heavily influenced by it, which makes both the tool and the platform "naturally" work well with the pattern.  Gossman just gave a PDC talk.

-Gossman

[lau...@galasoft.ch]

You like Gossman? Meh... :) By the way aren't you supposed to be frolicking far away from the intertubes? And also, when can i take you out for dinner in Zurich? Laurent -- Sent from mobile ----------------------------- From: "John Gossman" Subject: Re: [WPF Disciples] Re: "Advanced MVVM" Book Review Date: 13th March 2010 08:55 I like Gossman, but undue credit goes his way. Other folks were using MVVM terminology inside Microsoft before WPF. The WPF and Sparkle teams were heavily influenced by it, which makes both the tool and the platform "naturally" work well with the pattern. Gossman just gave a PDC talk. -Gossman On Fri, Mar 12, 2010 at 11:22 PM, Glenn Block wrote: > I like Fowler, but undue credit goes his way. He didn't name anything. He > compiled the pattern that others were already using. > > > > On Fri, Mar 12, 2010 at 2:20 PM, Bill Kempf wrote: > >> If it's just separation of code concerns from designer concerns we go >> 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. >> >> On Fri, Mar 12, 2010 at 5:16 PM, Evan Lang >> wrote: >> > If we're concerned with whom deserves credit for the invention of MVVM, >> it probably belongs to someone in the video game industry, though I couldn't >> begin to guess who. I dunno if any of them ever put a name to it, but >> separating code concerns from designer concerns WRT user interfaces is >> something they've been doing for a long, long time. >> > >> > -----Original Message----- >> > From: wpf-di...@googlegroups.com [mailto: >> wpf-di...@googlegroups.com] On Behalf Of Colin Eberhardt >> > Sent: Friday, March 12, 2010 1:16 PM >> > To: WPF Disciples >> > Subject: [WPF Disciples] Re: "Advanced MVVM" Book Review >> > >> > I had not realized it was a parallel discovery (or invention >> > 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. >> > >> > On Mar 12, 9:05 pm, Bill Kempf wrote: >> >> Arghhhhh!!!! >> >> >> >> 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. >> >> >> >> On Fri, Mar 12, 2010 at 3:50 PM, Colin Eberhardt >> >> >> >> >> >> >> >> wrote: >> >> > Peter wrote: >> >> >> 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 >> >>

[Glenn Block]

I was just wondering the same thing.:-)

[Glenn Block]

Yea, this Gossman guy get's way too much credit. I mean how can I have time to make up all these patterns while he's out travelling he world :-)

[Bill Kempf]

I didn't spend any energy focusing on who coined it first. I gave
credit to both folks that published articles on the pattern.

I'll concede that Fowler often gets credit for patterns found in
private groups, even when his published papers specifically talk about
the origins of the pattern. In fact, I believe you're correct that PM
is one such occasion. However, since he was the first to publish, he
still deserves citation in discussions.

See, arguing over whether or not he deserves some credit is spending
way to much energy focusing on who coined it first ;).

[Bill Kempf]

Thanks for helping me make my last point :).

Most "findings" of this nature, including scientific discoveries, are
made by groups of people. The person that gets "credit" is generally
the first to publish, regardless of how much involvement (from none to
sole person involved) they had in the actual discovery. Quibbling over
whether or not credit is deserved is an interesting historical
exercise, but academically irrelevant. You can't cite works not
published.

[Karl Shifflett]

Can see I missed all the drama from yesterday.

Josh, if they are shooting at you, rejoice, you must be doing the right
thing.

Now, it's time for some classic Joan Jett, MVVM, XAML Power Toys for SL4,
and two new addins for Visual Studio 2010.

A nice relaxing day...

kdawg

[Josh Smith]

KDAWG is my hero! :)

[Michael D. Brown]

What is Binding if not a direct reference to the VM? The infrastructure handles all of that for you but it’s still a reference. INPC (and events in general) are a framework supported implementation of Observable. I could picture Fowler’s presentation model as implementing the observable pattern and the View responding to the “events” the PM fires.

 

There is no significant difference between the two patterns. MVVM isn’t a refinement of PM it can’t be because they were discovered at the same time. They just happen to be the same phenomenon discovered by two different scientists.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Glenn Block

Sent: Saturday, March 13, 2010 12:37 AM
To: wpf-di...@googlegroups.com

[John Gossman]

Fowler says PM is known as ApplicationModel by some Smalltalk folks.  The guys who were talking about ViewModels at MS were former Smalltalk folks.  I suspect a common origin even earlier (the Phoenicians perhaps?).

[Josh Smith]

I think the common origin is common sense.  MVVM is just another name for "You do your job, I'll do mine."

Josh

[Justin Angel]

Hi Folks,

Great feedback everyone, thanks for taking the time to read my review
and comment on it.
I'll edit the blog post to mention I'm out-gunned 1 to many about the
quality of this book and link back here.

Allow me to respond to each claim individually.
The quotes aren't direct quotes, but how I perceived these comments.

1. "MVVM is about 1 thing - separating the View from the ViewModel. I
don't know why you would think that calling out Visual States in the
View so the ViewModel can maintain the Visual State of the View has
anything to do with that?" - By Peter O'Hanlon, et al

Some of you disagree with VSM being a core part of MVVM.
You're entitled to your own opinion. And you're also wrong.
I'll be more then happy to discuss this on a separate thread or maybe
do a quick writeup later on.
Even without VSM, you'll have Visual States in your View.
Not calling them out as such, just leads to a more unmaintainable
architecture and a very bad designer exprience.

2. "Josh wasn't trying to write a good gaming tutorial book" - Cory
Plotts

Good, because this isn't a good gaming samples.
If 50% of lines of code in the book and sample code are dedicated to
gaming, I'd hope they have some added value for the reader.

3. "MVVM isn't limited to WPF and Silverlight. You can build MVVM
with some pieces of wood and yarn!" - Evan Lang, et al

Josh is a WPF expert.
The book uses WPF as it's chosen platform.
It's being heavily published in the Silverlight & WPF community.

I assumed it would have something to do with WPF & Silverlight.
Otherwise, let's rename the book to "Advanced MVVM: For Stone Masons
and Wood Cutters".

4. "MVVM isn't about it's implementation." - Bill Kempt, Glenn Block,
et al

Right, but with 1,500-2,000 Lines of sample code, I'd hope the
implementation was relevant.
If the reference code in this book isn't up to par with the minimum
bar, then I can't help it - it's not a good book.

5. "Commands aren't an integral part of MVVM" - Bill Kempf

Yep. Behaviours are good substitute for designer-friendly domain-
specific commands.
However, some mechanism of invocation for seperating View Actions from
View Model code is required in all forms of MVVM IMO.

7. Some valid concerns about VSM and MVVM by Bill Kempf. Good
questions, Let's talk about this in a separate thread later on, k?

8. "Allah/Jesus/Yahawe/Buddha/John invented MVVM." - some of you

Sure.

9. "I think choosing a game sample for an MVVM book was the right
choice" - Michael Brown, et al

Good for you. Care to share the reasons with the rest of us?

10. "Having 1 sample of Commands and 1 sample of Data binding is
enough for an MVVM book" - Michael Brown

No, it's not.
Either the book is about MVVM, or it isn't.

If it's about MVVM, it'll have some MVVM theory or MVVM implementation
details.
Since there's almost no MVVM theory in the book, I'd just assume it's
about implementation.
If it's about implementation, it should have a sample of however the
author choose to implement MVVM's core principles.

11. "Refined Samples are complex hence bad." - Michael Brown

Choose a simpler problem domain. My day-to-say problem domain one is
Cows. Cows are awesome. Also, tasty.

12. "Code can't be too simple and too complex at the same time." -
Michael Brown

Is that a new axiom you've invented?
The Gaming infrastructure code in this book is an unholy mess.
The MVVM code in this book isn't up to par with minimal expectations.

13. "DataTriggers are awesome" - Michael Brown

Maybe. That's an open question for some. Somehow though, everyone in
SilverlightLand manages without them.
Maybe DataTriggers are just a worst practices letting you mix
ViewModel logic in View markup.

14. "Saying Don't buy this book is crazy" - Glenn Block

This book will end having hundreds of frustrated readers who will
abandon MVVM just because of how bad this book is.
It happened to TDD, it happened to IoC, it'll happen to MVVM.
If you've got facts to convince me I'm wrong, I'd be more then happy
to admit I'm wrong and change the blog post.

15. "God came to me in a dream and told me to kiss Justin" -
Completely different email thread :)

-- Justin Angel

[Glenn Block]

Thank you oh great one for your imparting your wisdom! As for me I will continue to wallow in my state of ignorance.

 

Cheers

Glenn

[Glenn Block]

We can agree to disagree :-)

 

The fact that that I don't have to "hold" the reference and that i let binding to the work for data and behavior IS the big difference. That's why we look at folks who hold references to the VM in code and say "Wait, why are you doing it that way?"

Maybe John can weigh in, but my understanding of why this gained so much popularity on the blend team was because of how well it leveraged the underlying technology in order to promote better separation, testability, etc.

 

Glenn

[Bill Kempf]

Justin,

I respect your opinion, and not all of what you say is wrong, but
"You're entitled to your own opinion. And you're also wrong." is more
than a bit out of line. I also find it quite astonishing that you'd
make such a statement after everyone else gave you reasoned responses
as to why you got this one wrong. If nothing else, the fact that VSM
didn't exist when the pattern came to be should be enough for you,
even if you don't agree with the rest. I think you'll come to regret
this quote. At least, I hope you do.

[Dr. WPF]

Okay, I managed to stay quiet so far, but you've crossed a line now! ;)

> 13. "DataTriggers are awesome" - Michael Brown
>
> Maybe. That's an open question for some. Somehow though, everyone in
> SilverlightLand manages without them.
> Maybe DataTriggers are just a worst practices letting you mix
> ViewModel logic in View markup.

This is not an open question! Data triggers (and triggers in general) are
awesome, period.

Just because you can "manage" without something doesn't mean you should.
(People managed for centuries without indoor plumbing, but isn't the world a
better place now that we have it?)

Data triggers do not imply VM logic in the view. When used properly, they
provide pure view logic.

And *anything* can be a bad practice if used wrong. Take VSM, for
example... I've had to untangle too many VSM knots for designers who have
gotten themselves into "state hell". The moment a developer has to debug a
designer's view, we have a broken workflow. (And the things they do in the
code behind is atrocious!)

Having said that, I think VSM is great, when used correctly. It is
certainly more toolable. But I'd still argue that trigger-based XAML is
better formed than VSM-based XAML.

Hopefully we will eventually get triggers in SL. If we don't get property
triggers, I will settle for data triggers because... shhh... don't tell
anyone, but data triggers can be used as property triggers. ;-)

[Justin Angel]

Agreed. Reading that out of context does makes me sound a bit more off an
a**-hole than normal. Sorry about that.

I was under the impression we're all on the same page on VSM.
We've had many successful discussions on VSM up until yesterday and it
seemed there's wide consensus around that issue.

VSM has been an integral part of Silverlight since Silverlight 2 shipped.
From everything I've seen and heard there's strong consensus around VSM in
the Silverlight community.
While I respect the historical baggage WPF has to carry around, I can't see
why we need to be stuck in 2005 when discussing a 2010 Book.

-- Justin

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Bill Kempf
Sent: March-13-10 11:23 AM
To: wpf-di...@googlegroups.com

[Jaime Rodriguez]

My 2c,

MVVM is about separation of View and Model; preaching that we should focus on a View-specific detail seems like bad advice to me.
Besides Justin, I have never met or discussed MVVM with any one that thought VSM was a critical pillar to the pattern. I have coded, reviewed, and taught to people developing more than 50 apps using MVVM and VSM probably came up in 2% of these, since most are WPF apps.

I have not read the book yet, so can't endorse either way.. but I have read many, many articles by Josh and I usually learn something. I could never tell anyone not to buy his book or not to read his articles.

Sorry to be blunt. A lot is learned in this exclusive group, and to question the credibility of the group with a "you are all wrong" was disappointing so I had to chime in.

Justin, I really don't need a reply. Let's end the thread. My points above are my personal experiences - they can't be changed by anyone in the thread, it is merely what I have experienced.

Cheers!! Thanks for all of you including Justin for having the guts to speak up. I do think we learned something even from this thread :)

[Shawn Wildermuth]

Are we still talking about this? Really?

Thanks,
Shawn Wildermuth
http://wildermuth.com

Note: This was typed on a big ole laptop so any misspellings and
punctuations are completely my fault…not my phone’s.

[Sacha Barber]

I agree with Daniel, Its how I do things, I too believe if code behind is used correctly why not, and I too will use MVVM - M when I want to create a nice app which still uses View and ViewModel even without the Model sometimes.

On Fri, Mar 12, 2010 at 9:53 PM, Daniel Vaughan <dbva...@gmail.com> wrote:

I enjoyed the book. Thought it was solid. Josh gets it, and it's how I
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>

>
> > 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

--
Sacha Barber
sacha....@gmail.com

[Peter O'Hanlon]

Justin

 

"1. "MVVM is about 1 thing - separating the View from the ViewModel. I
don't know why you would think that calling out Visual States in the
View so the ViewModel can maintain the Visual State of the View has
anything to do with that?" - By Peter O'Hanlon, et al"

 

Really? Nobody stated that, or even implied it; we specified that MVVM was separating the view from the model with this great layer in the middle. I did question your assertion about VSM; I'm a WPF developer and I never use VSM. I have awesome databinding and triggers to take care of things for me.

--
Peter O'Hanlon

[Michael D. Brown]

I do agree with one paraphrase you made. "Data Triggers ARE awesome" and VSM
is just a substitute for the lack of DT's in Silverlight. Even when
discussing the decision to forgo data triggers and use the VSM, the
Silverlight team said that there was a learning curve associated with data
triggers that made them difficult to grasp and that VSM was a compromise
between raw power and approachability.

Having a discussion with a colleague about the book, we discovered that
Josh's implementation of the view model (using events to notify the view of
state changes) makes applying VSM a trivial task should one be so inclined.
This fact in and of itself (even ignoring the fact that VSM didn't exist
when MVVM was discovered) points that VSM is an implementation detail and
not a "pillar" of MVVM.

I have no more to say on the topic. I've said what I've had to say. If some
of it came across as aggressive blame the internet. It was not my intent. My
intent was to make logical debate regarding some of your statements that are
misleading. In return you distilled my statements into a straw man that was
easier for you to attack. Then said I was wrong based on a statement that I
didn't make. Saying "you're entitled to your own opinion. And you're also
wrong," shows a clear disregard for even basic logic. An opinion cannot be
wrong by sheer virtue of it being an opinion. And for that fact, I'll bow
out of this discussion. Congratulations, I'm sure your click bait was a
successful campaign.

--Mike

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Justin Angel
Sent: Saturday, March 13, 2010 2:04 PM
To: WPF Disciples
Subject: [WPF Disciples] Re: "Advanced MVVM" Book Review

[Sacha Barber]

Its a good book do not worry, anbout what Justin thinks, thats just 1 person man.

On Sat, Mar 13, 2010 at 1:10 AM, Josh Smith <flappl...@gmail.com> wrote:

I wouldn't say it's all about the sales, but mostly. ;)

Other than the extra income, this book is something I'm proud of.  It's easy to criticize someone else's work on the Web, so I am used to receiving all types of crap from people about my publications.  I know that I'm happy with the book, and think it's a worthwhile achievement.  If someone else gets off by bashing my work in public, that's their prerogative.

Josh

On Fri, Mar 12, 2010 at 5:05 PM, Glenn Block <glenn...@gmail.com> wrote:

It's all about sales eh :-)

On Fri, Mar 12, 2010 at 5:04 PM, Josh Smith <flappl...@gmail.com> wrote:

And, plus, by making such a big stink about how awful my book supposedly is, I assume it will make the more skeptical of his readers intrigued about the book.  Who knows, it might even lead to some sales! :)

On Fri, Mar 12, 2010 at 5:03 PM, Josh Smith <flappl...@gmail.com> wrote:

Yeah, I agree, but what's the point in arguing with someone over it?  I can't force him to edit his own blog, so whatever...

On Fri, Mar 12, 2010 at 5:01 PM, Glenn Block <glenn...@gmail.com> wrote:

Having a review is great. Saying "Don't buy this book" personally I think goes over the line from personal preference.....

On Fri, Mar 12, 2010 at 4:45 PM, Josh Smith <flappl...@gmail.com> wrote:

Thanks for the book review, Justin. 

Josh

On Fri, Mar 12, 2010 at 10:56 AM, Justin Angel <J...@justinangel.net> wrote:

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.)

--
Sacha Barber
sacha....@gmail.com

[Peter O'Hanlon]

Hell yeah. I like it, I like it a lot - and considering it was my hard earned spent on it (and I'm such a tightarse), it had to be good to get my approval. BTW, it's so good that I've got 2 copies; a personal one and one for the office.

--
Peter O'Hanlon

[John Gossman]

Troll