A Rose by any other name...

[Bill Kempf]

Just published a new blog post about the M-V-VM name (http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!797.entry).  I'd be very interested to hear other people's thoughts on this one.

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery.  Bugs are features.

[Josh Smith]

How about we call it MVTronix9000?  :-P

[Bill Kempf]

OK, I'll put you down as voting for MVPoo ;).

[Josh Smith]

hahahha

[Sacha Barber]

Having worked with the SCSF block which was MVP all the way, its just a more WPF version. Oh well, they both work.

---

Date: Mon, 4 May 2009 12:25:04 -0400
Subject: [WPF Disciples] A Rose by any other name...
From: wek...@gmail.com
To: wpf-di...@googlegroups.com

---

Windows Live Messenger just got better. Find out more!

[Sacha Barber]

yeah thats real catchy.

---

Date: Mon, 4 May 2009 09:52:36 -0700
Subject: [WPF Disciples] Re: A Rose by any other name...
From: flappl...@gmail.com
To: wpf-di...@googlegroups.com

---

Share your photos with Windows Live Photos – Free. Try it Now!

[Corrado Cavalli]

I agree on many points of your post but I also think that changing the name would result in additional confusion and, from my point of view (or Viewmodel if you like J), Model-View-ViewModel or M-V-VM has now become the official name of the pattern by “popular demand” so I’ll stay with the current verbose name.

 

-Corrado

[Mike Brown]

Bill,

  I posted my comments on your blog. Suffice it to say I agree with you (we Hoosiers have to stick together).

[Bill Kempf]

There's some "insiders" (can't explain more than that publicly) that want to change the name to just View Model.  They're in a position where they may actually be able to do away with the current "popular demand".  That's why I'm interested in discussing this.  The academic in me wants to stick with Presentation Model.  The pragmatist in me says View Model is more likely to be accepted and is certainly better than the tongue twisting M-V-VM.  The realist in me says M-V-VM may be here to stay no matter what I like.

On Mon, May 4, 2009 at 2:57 PM, Corrado Cavalli <corrado...@gmail.com> wrote:

[Bill Kempf]

Even if one of us is a Husker transplant that barely knows what a Hoosier is? ;)

 

Yeah, we seem to be in agreement, though I'm not sure if you've got the same heartburn feeling I do over such a trivial issue. :)

[Peter O'Hanlon]

I say "Sod It. From now on, MVVM will be known as Bernard."

--
Peter O'Hanlon

[Bill Kempf]

LOL.  I prefer George.

 

"I will name him George, and I will hug him, and pet him, and squeeze him."

"And pat him, and pet him, and..."

"And rub him, and caress him, and..."

 

OK, it's official.  I want to drop M-V-VM for NABR (Not a Bunny Rabbit)!

[Peter O'Hanlon]

Excellent Bugs reference, but I'm not so sure about George. My Father In Law was called George, and he complained that only gormless things ended up being called George (not that I'm implying any gormlessness on his part, he's really quite intelligent).

--
Peter O'Hanlon

[Bill Kempf]

Yeah, but is NABR gormless?

[Peter O'Hanlon]

Good point. NABR; The Pattern Formerly Known as MVVM. All it needs is a symbol.

--
Peter O'Hanlon

[Bill Kempf]

^^vv^^ works great as a symbol ;).

[Peter O'Hanlon]

I like it. I'm going to see if I can fit it into a blog post somewhere.

--
Peter O'Hanlon

[Marlon Grech]

The way I see it MVVM is the name of the pattern (ok some may argue that Presentation Model is the real pattern name which I don't agree 100% with, but that is a different matter) who ever finds it hard to pronounce it, will just call it ViewModel. I don't know how or why we should be saying that the community should always say ViewModel.

 

MVVM yet when I am speaking I call it VM or ViewModel... no need to make a revolution :)

 

I think MVVM is really getting the community going crazy lately.... let's have some fun with reflection, DLR and what something crazy like that... hehe... get our heads a bit distracted :D

 

P.S I get the point of the post Bill. I am a big beleiver of Patterns and know that the name is super important because at the end of the day patterns are there so that you do not say... I want I class which can be instinsiated only once, you just say I want a Singleton. Yet I don't see the difference between MVVM and ViewModel if the meaning will be the same.... I would stick with what is already out there....

 

just my 2 cents as my Karl Shiflett used to say... karl where are you???? MS you stole him from us :(

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

The importance here is that the name, by itself, doesn't convey any meaning.  Consistent use of the name is what "binds" it to the meaning (what the pattern is).  When a pattern has two names, you're not using the names consistently, and thus are diluting the "meaning" behind the name.  It's worse when one of the names is used by a smaller community, while the other name is used by a larger community.  Outside of WPF, this pattern is called Presentation Model.  When someone from that larger community talks with, or worse, tries to join the WPF community, the name M-V-VM means nothing to them.  When you try and explain the pattern to them, they find it difficult to understand, because you're describing something that sounds like a pattern they already know (because you ARE).  Names are important.  That's the whole point behind patterns, BTW.  All of the patterns in GoF already existed when the book was published.  What was revolutionary was that GoF finally applied NAMES to these patterns, which enabled us to discuss the patterns at a much higher level than we'd been able to previously.

 

Even if there weren't the issue of two names for the same pattern, I'd still argue that there's an issue with MVVM.  That's such a difficult name that I can't tell you the number of times I've seen things like "ModelView-View-Model" used in discussions, which much like the two name dilemma, leads to confusion and break down in communication.  In a vacuum, View Model seems ideal.  Given history, Presentation Model is probably the better name.  Given the momentum behind WPF and MVVM, ^^vv^^ may be here to stay.

[Mike Brown]

Funny I was going to say us Corn Huskers (cuz that's all that's in Indiana right?) but realize it implied Nebraska. Don't worry I still have no clue what hoosier means (outside of being a nice segway into a pun as in "Hoosier Daddy") I'm from Chicago originally with a short stint in WI.

 

BTW, I haven't confirmed this but I believe the abominable snowman character was originally inspired by Lenny from "Of Mice and Men" the voice even sounds like a direct imitation of Lon Chaney's rendition http://www.imdb.com/title/tt0031742/.

[Paul Stovell]

I'd like to see "ViewModel" dropped just because I'm so sick of seeing code like this:

• XYZView.xaml
• XYZView.xaml.cs
  
• XYZViewModel.cs

It's like suffixing your classes with Observer or Factory or Singleton - totally unimaginative :)

- Paul

--
Paul Stovell
http://www.paulstovell.net

[Josh Smith]

>> It's like suffixing your classes with Observer or Factory or Singleton - totally unimaginative :)

 

That's a benefit in my opinion.  I detest "imaginative" things that force me to think about things that I shouldn't bother thinking about.  For me, keeping it brain-dead simple is crucial, because the problems involved with creating functional software is complicated enough already...  :)

 

Josh

[Mark Wilson-Thomas]

Nice to hear the wonderful term “gormless” bandied about on a technical discussion list – makes me feel right at home as an exiled North Yorkshireman…

[Peter O'Hanlon]

If you like, I'll talk about Black Pudding, Newcastle Brown and Huddersfield, if that'll make you feel better.

--
Peter O'Hanlon

[Laurent Bugnion [MVP]]

It is a benefit for me too. I don’t use “View” as a suffix though, because it really depends what the view does, but using the same same as the View plus a “ViewModel” suffix makes things easy and clear.

 

Cheers,

Laurent

[Bill Kempf]

I'll agree with that... although a ViewModel suffix tends to make names rather long winded.  I refuse to use VM, though, and not just because the framework guidelines say not to.

[Peter O'Hanlon]

To be honest, I tend to use a folder structure to identify what's View and what's ViewModel. This leads to the following type of structure:

 

MyProject

|--View

|----Login

|----AddStock

|--ViewModel

|----Login

|----AddStock

The namespace reflects the relevant source, so I'd typically have:

 

namespace Company.MyProject.View

{

  public class Login{}

}

namespace Company.MyProject.ViewModel

{

  public class Login{}

}

--
Peter O'Hanlon

[Bill Kempf]

I dislike this, if for no other reason that it violates the framework guidelines.  It can be a royal pain to use code where types have names that are identical except for the namespace.  If it works for you, great!  I wouldn't recommend it as standard practice, though.

[Peter O'Hanlon]

"I dislike this, if for no other reason that it violates the framework guidelines." - Yup, but they are guidelines only. To be honest, I've never had any problem with this type of architecture - it works fine for us and makes it easy to tell what's related to what at a glance. We started off using View at the end of views and ViewModel at the end of view models, but this goes counter to the rest of our system developments where types are named for purpose, and don't have to have artificial constructs such as View/ViewModel or Model added at the end.

--
Peter O'Hanlon

[Bill Kempf]

"We started off using View at the end of views and ViewModel at the end of view models, but this goes counter to the rest of our system developments where types are named for purpose, and don't have to have artificial constructs such as View/ViewModel or Model added at the end."

 

I'd argue you've failed.  The View and the ViewModel serve very different purposes, and yet they have the same name, so they sure don't seem to be named for purpose.  To me, what's worse is that this makes it harder to actually work on the project.  Open both the V and the VM classes, and it becomes next to impossible to distinguish which is which in the list of open editors, for instance.  Navigation facilities in the IDE (of which R# has many, and VS2010 is adding to) become difficult if not impossible to use, due to the duality of names.  Intellisense is harder to use.  Fully qualified type names are needed more frequently.

 

Again, if this works for you, great!  But I couldn't use this design.

[Peter O'Hanlon]

As our views just tend to be fairly dumb in terms of code behind, it's very rare that we bother with having the .xaml.cs files open. That's the beauty of the whole MVVM framework as far as we're concerned, and I'm not going to start the whole code behind argument again here. As far as the argument that the View and ViewModel serve very different purposes, that's true - but only to a certain extent; a Login view and a Login view model both serve to support the ability for a user to log in, which is one of the reasons that we ultimately settled on this architecture.

 

As you said, you couldn't use this design, but it works for us. We also don't use R#, so it's not that much of an issue for us. We've never had issues with intellisense, and we also haven't had issues with fully qualified type names (again because our UIs tend to be fairly clean in the code behind).

 

Oh well - horses for courses.

--
Peter O'Hanlon

[John Gossman]

Like others on the thread said, I think the full pattern name is M-V-VM...but I after introducing it, I use ViewModel as a shorthand.  PresentationModel doesn't capture the unique WPF aspects of XAML and data-binding...so my feeling is there is an inheritance heirarchy of patterns here:  Model-View separation is the most general, MVC and PresentationModel are sub-patterns of that, M-V-VM is a sub-pattern of PresentationModel.

[John Gossman]

How about explaining privately?

[Marlon Grech]

I'm with John on this...  Presentation Model is similar to View Model.... yet when Fowler explained it there was no WPF ... I know that patterns are not tied to technologies yet in this case I see it a bit tied with the technology!

 

and when you want to explain the pattern to people knowing Presentation Model I never had any problem.... I say this is similar to Presentation Model BUT..... There was never any problem.... Bill have you ever tried explaining this to others? what are the problems they are facing to understand this? how is this confusing them?

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

What comes after the BUT?  What distinguishes MVVM from PM in ANY way? Note that the PM description makes specific mention of .NET data binding and the hopes that a future framework (yea WPF!) could enable something along those lines to make it easier to implement the pattern.  The ONLY answer I can ever give when explaining this to someone is that there is no difference. We just have two names, and the WPF community prefers MVVM. That doesn't sit well with some folks, myself included, for the reasons I've already stated.  Yes, once explained that the patterns are the same, we can move forward with discussions, but the fact that I had to try and explain this, and the fact that the explanation is hollow to many folks, isn't a good thing.

[Marlon Grech]

Like for instance the importance of Commands in MVVM.... Like the fact that a VM implements INotifyPropertyChanged..... The concepts are the same but the implementation is much different.

 

Now you may argue, patterns are all about concepts and not implementation..... and we start arguing again :D

 

haha... anyway back to our conversation...

 

and please note.... Quote from Fowler's blog
Also Known As: Application Model

 

This is just my opinion but I like MVVM as it is. I don't see any need to change it... I don't think it is confusing....

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Josh Smith]

I agree with John and Marlon.  I stand by what I put in my MSDN article about MVVM:

 

"In 2005, John Gossman, currently one of the WPF and Silverlight Architects at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler's Presentation Model, in that both patterns feature an abstraction of a View, which contains a View's state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF to simplify the creation of user interfaces. In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms."

 

Josh

[Bill Kempf]

INPC is a red herring, since again, PM discusses it (indirectly by discussing .NET data binding, which is reliant on this interface). Commands I'd argue are equivalent to the events discussed in the pattern and are no more than an implementation detail.

 

So, you're entire argument rests on there being an implementation difference.  I simply won't except that.  Patterns are about defining a vocabulary for concepts, not implementations.  If you go down the route of using different names for different implementations, then every time you implement a pattern in any new language you'll be using a new name, and communication will suffer.  This is wrong.

OK, you do have a point about the AKA note.  Some patterns, for historical reasons, do have multiple names.  That's unfortunate, but a reality.

[Marlon Grech]

"If you go down the route of using different names for different implementations, then every time you implement a pattern in any new language you'll be using a new name, and communication will suffer."

I agree on this... But come on.... this is much different!

 

I don't know what to say... I guess different people have different idea and opinions.... Sorry I don't agree with you.... They are similar but I say they must be distinguished.... I cannot see someone telling someone else "Do a MVVM in your Win32 app "....  This pattern is different! Ok implementation wise but I see the use of having a different name!

 

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

Really?  Because I know a lot of folks applying "MVVM" to WinForms applications. This very thing was brought up in the mvvmref discussions as something we should enable. There's not much difference between a WinForms implementation following MVVM and a Win32 implementation. This is a pattern.  The implementation is irrelevant.  I can live with an AKA situation (reluctantly), but attempts to justify this as a refinement will only fly if you can differentiate between the patterns, and not their implementations.

[Marlon Grech]

The way I see it is that these guys are implementing Presentation Model but not MVVM.... I see it different... and that is why I state that they should have different name....

 

Call me stupid if you want but that is my opinion... :) 

 

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

Why are they implementing Presentation Model? Why isn't it George, since the implementation is different?

 

I'm not calling you stupid by any means, but I can't agree with you, and I doubt most folks in the wider community would be able to either.  Your changing the definition of an accepted industry term: pattern.  You can't call MVVM a pattern, if what distinguishes it is solely the implementation.

[Marlon Grech]

It's not just implementation.... it's the way of thinking.... thinking commands... Routed Commands.... DataBinding (WPF one)

 

I don't know.... maybe I am missing something.... but I don't think I am changing the defenition of a pattern...

 

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

All of that "thinking" is thinking about the implementation.  The pattern hasn't changed because of how you've implemented it.  The pattern has remained the same, with three principle actors, Model, View and ViewModel, with known responsibilities (View - display and user interaction, ViewModel - state and interaction logic, Model - domain logic and state).  The fact that you've used ICommand implementations and data binding doesn't change how you think about the pattern, only how you think about implementing the pattern.  Even within WPF, how you implement the pattern is variable.  I can easily implement an application that follows the pattern but never once uses an ICommand, for instance.  Heck, I could even totally avoid data binding, as painful and stupid as that would be, and I'd still be implementing the same pattern.  I know of one project on CodePlex that uses a radically different data binding infrastructure that's not dependent on INPC.  Would you honestly tell that person he's not following MVVM if he uses his framework instead of the traditional data binding?

[Mike Brown]

Here's my thought. Even though C# supports a different implementation of the Singleton pattern than C++, we don't call it Statically Constructed Single Object because of those implementation details. We call it singleton as well.

 

Yes WPF has more features that change HOW you implement Presentation Model/View Model...but at the core the two are the same. If you look at the PRISM guidance, they call it Presentation Model. Presentation and View are semantically the same...as are the two patterns. I believe that we are defeating the purpose of a pattern language by changing the name of a pattern because of a few implementation details.

[Bill Kempf]

We transplanted Hoosiers are agreeing again ;).

On Tue, May 5, 2009 at 12:55 PM, Mike Brown <mbro...@gmail.com> wrote:

Here's my thought. Even though C# supports a different implementation of the Singleton pattern than C++, we don't call it Statically Constructed Single Object because of those implementation details. We call it singleton as well.

 

Yes WPF has more features that change HOW you implement Presentation Model/View Model...but at the core the two are the same. If you look at the PRISM guidance, they call it Presentation Model. Presentation and View are semantically the same...as are the two patterns. I believe that we are defeating the purpose of a pattern language by changing the name of a pattern because of a few implementation details.

[Jaime Rodriguez]

Wow, long thread..  I will try to comment here on all the points I just read.   

 

Bill,   

·         I have to +1  John’s ask “if there is a valid concern for the name, beyond how long it is to title books and articles, let’s hear it, publicly or privately, what ever you are comfortable with.   Community-wise, you all have contributed to the pattern much more than Microsoft (who did the name) so we should stick to a name we are all comfortable with to avoid confusing others.  Can you explain why you see a difference between “M-V-VM” and just “ViewModel” in name??  

·         Any one who has ever discussed this with me, has heard that the “name” does not matter.  The P&P folks and me did try to use PM two years ago, and it just was not sticking beyond the 50 people who were in Prism v1 councel..  Today, after learning the lessons, I  would vote for M-V-VM because that puts me into context with two other well  recognized UI patterns “Model View Controller” and Model View Presenter”.  I have to explain this to people who don’t read fowler, and most have heard of MVC and MVP, but not heard of Presentation Model, so when I said MVVM = PM == delicious rugables they stared at me equally confused.

·         I do disagree that Commands == Events.  Sorry but that is too big of a bridge for me to jump.     Beyond coupling, commands have CanExecute, are binding friendly, etc..   In my book, Apples != pears.  Close, but not close enough.

·         I am not sure I care much for calling the pattern WPF or XAML specific.  So I am not opposed to someone saying they are using M-V-VM in Windows Forms.    

Again,  I think the answer here is getting to the root of the name problem; if you are trying to give credit to Fowler,    I wonder if that is necessary.    All of the disciples are imo an “elite” group of architects/developers, who I am sure are far above the average curve, but even then I would be willing to bet $1 that half of us ( me included, and John included) had never heard of Presentation Model until someone told us ‘MVVM == PM from Fowler’…     so worrying about attributing something that no one knew before seems unnecessary.

I don’t see any real advantage between “View Model” and “M-V-VM”; to be candid I use those interchangeably and I doubt we need to formalize one name over the other .   

 

 

 

 

 

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Bill Kempf

Sent: Tuesday, May 05, 2009 9:41 AM
To: wpf-di...@googlegroups.com

[Laurent Bugnion]

Are we on the verge of our first ever flame war in the history of the Disciples? I say fight, fight, fight :) maybe we should start this discussion again over beers next time :)

Laurent
--
Sent from mobile

-original message-
Subject: [WPF Disciples] Re: A Rose by any other name...

From: Bill Kempf <wek...@gmail.com>
Date: 05.05.2009 19:16

We transplanted Hoosiers are agreeing again ;).

On Tue, May 5, 2009 at 12:55 PM, Mike Brown <mbro...@gmail.com> wrote:

> Here's my thought. Even though C# supports a different implementation of
> the Singleton pattern than C++, we don't call it Statically Constructed
> Single Object because of those implementation details. We call it singleton
> as well.
>
> Yes WPF has more features that change HOW you implement Presentation
> Model/View Model...but at the core the two are the same. If you look at the
> PRISM guidance, they call it Presentation Model. Presentation and View are
> semantically the same...as are the two patterns. I believe that we are
> defeating the purpose of a pattern language by changing the name of a
> pattern because of a few implementation details.
>

--

[Josh Smith]

No need for a flame war...we can agree to disagree.  Let's keep it friendly. :)

Josh

[Josh Smith]

No need for a flame war.  I think we can all respect each other's opinions enough to avoid that.  ;)

 

Josh Smith - pacificst

On Tue, May 5, 2009 at 10:43 AM, Laurent Bugnion <lau...@galasoft.ch> wrote:

[Mike Brown]

It's not a matter of giving credit to Fowler, it's just that outside of the WPF community, the pattern is known as Presentation Model. I just ran across a message the other day where someone was asking "what's the difference between VM and Presentation Model"? I've been doing a TON of reading lately on semantics and language communities thanks to David Hay. The most common issues in software development arises from semantics, IE the developer hears a term and thinks of something different than the business user. For instance if I say class to a developer, a teacher, and a retail taxonomist all three are going to think of three vastly different things. There's too much of a battle with language across domains without adding intra-domain differences.

 

That being said, the WPF community DOES constitute it's own semantic community. Within the context of WPF development, saying View Model and MVVM provides everyone with a clear picture of a specific pattern about which I'm speaking. At this point it's like fighting against modern usage of "myself". Even though I don't like either, I have to accept the fact that language is by it's very nature fluent. That doesn't mean that I won't continue to use "myself" properly or refer to MVVM as Presentation Model (because honestly, who in the WPF community doesn't understand what I mean when I say that either, and I get the added benefit of a wider audience understanding what I'm saying as well).

[Bill Kempf]

On Tue, May 5, 2009 at 1:37 PM, Jaime Rodriguez <jai...@microsoft.com> wrote:

Wow, long thread..  I will try to comment here on all the points I just read.   

 

Bill,   

·         I have to +1  John’s ask “if there is a valid concern for the name, beyond how long it is to title books and articles, let’s hear it, publicly or privately, what ever you are comfortable with.   Community-wise, you all have contributed to the pattern much more than Microsoft (who did the name) so we should stick to a name we are all comfortable with to avoid confusing others.  Can you explain why you see a difference between “M-V-VM” and just “ViewModel” in name??  

The MVVM name is difficult to write (folks don't even do it consistently), and even worse to speak. Of the two, I prefer View Model (or ViewModel if you prefer), for this reason. But I wouldn't have dared bring that up myself, if I hadn't heard others calling for a change.

·         Any one who has ever discussed this with me, has heard that the “name” does not matter.  The P&P folks and me did try to use PM two years ago, and it just was not sticking beyond the 50 people who were in Prism v1 councel..  Today, after learning the lessons, I  would vote for M-V-VM because that puts me into context with two other well  recognized UI patterns “Model View Controller” and Model View Presenter”.  I have to explain this to people who don’t read fowler, and most have heard of MVC and MVP, but not heard of Presentation Model, so when I said MVVM = PM == delicious rugables they stared at me equally confused.

I'm not sure there's that many that have heard of MVP but not heard of PM... but I'm not sure it's that relevant. *shrug*

·         I do disagree that Commands == Events.  Sorry but that is too big of a bridge for me to jump.     Beyond coupling, commands have CanExecute, are binding friendly, etc..   In my book, Apples != pears.  Close, but not close enough.

OK, that's taking what I said out of context and extrapolating meanings I didn't intend to make.  Obviously there's a world of difference between commands and events, but those differences meant little beyond being an implementation detail when discussing the pattern.

·         I am not sure I care much for calling the pattern WPF or XAML specific.  So I am not opposed to someone saying they are using M-V-VM in Windows Forms.    

On that, we agree.

Again,  I think the answer here is getting to the root of the name problem; if you are trying to give credit to Fowler,    I wonder if that is necessary.    All of the disciples are imo an “elite” group of architects/developers, who I am sure are far above the average curve, but even then I would be willing to bet $1 that half of us ( me included, and John included) had never heard of Presentation Model until someone told us ‘MVVM == PM from Fowler’…     so worrying about attributing something that no one knew before seems unnecessary.

It's certainly not about giving credit to Mr. Fowler.  I think historical record clearly shows that both parties "discovered" the pattern independently at roughly the same time.  Both deserve credit, and are given credit by me.  No, this is about establishing shared vocabulary.  The larger community knows this pattern by a different name.  At the very least, we should acknowledge that, and I'd prefer we just use the name more broadly known.  It's really as simple as that.  We developers who target Microsoft platforms, and you MSFT fellows get enough grief about "lock in" and related topics, without adding to the issue by formulating our own vocabulary for things that already have an accepted vocabulary outside of our smaller community.

I don’t see any real advantage between “View Model” and “M-V-VM”; to be candid I use those interchangeably and I doubt we need to formalize one name over the other .   

--

[Mike Brown]

I swear that Bill and I are two separate people ;)

On Tue, May 5, 2009 at 2:04 PM, Bill Kempf <wek...@gmail.com> wrote:

It's certainly not about giving credit to Mr. Fowler.  I think historical record clearly shows that both parties "discovered" the pattern independently at roughly the same time.  Both deserve credit, and are given credit by me.  No, this is about establishing shared vocabulary.  The larger community knows this pattern by a different name.  At the very least, we should acknowledge that, and I'd prefer we just use the name more broadly known.  It's really as simple as that.  We developers who target Microsoft platforms, and you MSFT fellows get enough grief about "lock in" and related topics, without adding to the issue by formulating our own vocabulary for things that already have an accepted vocabulary outside of our smaller community.

[Peter O'Hanlon]

I prefer to think that we're a group of some of the best darned developers in the world who are passionate about what we do, and are prepared to shout out about what we love doing.

--
Peter O'Hanlon

[Jaime Rodriguez]

Thanks for response Bill.    Where do we go from here??  Do people care to vote for names now?  [How would we capture feedback from Silverlight folks? Should we? ]..

 

Have to agree with Peter that despite our blunt writing and loud passion, everything here is said with great respect.   Apologies if that does not come through on email.   

Below, I clarified my points from earlier, but no need to reply…   We could go on for a while, and instead I think we just need a vote..  If all the names are in the hat; else let’s get the names in the hat.

 

Cheers,  

 

 

·         MVP is a term we have used a lot at Microsoft for last five years; if you read the P&P stuff on client apps, etc..  You will see it a lot, so I would venture my audience (ISVs and breadth developers) are at 90% heard of MVP and < 10% heard of presentation model;  standardizing on that name is going to be a tough sell at this point.  Again, that audience is different from disciples (and to some extent different from WPF early adopters, but that audience is going to be moving to WPF and Silverlight this year and next so we are focused on them a bit). To put it into context, < 30% of that audience has ever heard of Martin Fowler, yet they write some pretty cool and business critical apps.

 

·         Across Microsoft, “Model-View-ViewModel and ViewModel are used interchangeably” ..  I use the full-name when I am introducing the pattern (e.g a training or event), titling a presentation, etc..  once I get talking about it or writing about it, I shorten it to “ViewModel”  (as that is where the magic happens).   This is standard for a lot of our products (long formal name but we use acronym, like WPF, or long name but we use codename, like Cider).  I am not saying that is not painful five times a year, just explaining how we think about it so that when voting you all can decide whether it is 2 or 3 choices: Presentation Model, ViewModel (with nothing else, ever), or Model-View-ViewModel (which shortens to ViewModel) .     I can’t see huge difference between 2 and 3; but that could be just me (since I drink the blue koolaid every day).

·         You coin commands and events  as a minor implementation detail;  I struggle with that; I think it is a significant detail because in .NET world we don’t have elegant ways to encapsulate logic in ViewModel using events. How are others keeping all logic in ViewModel using just events and not coupling to the views?   Sorry to not let it go, we can sideline it;  I am mostly curious cause if there is a simple, intuitive, decoupled way, I would love to embrace it myself.

 

 

 

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Bill Kempf
Sent: Tuesday, May 05, 2009 11:04 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: A Rose by any other name...

 

 

On Tue, May 5, 2009 at 1:37 PM, Jaime Rodriguez <jai...@microsoft.com> wrote:

[Peter O'Hanlon]

I vote MVVM, partly because this is what I've been evangelising about to my team for nigh on a year now, and changing at this late stage would seem like I was changing methodologies and trying to justify it. Secondly, Bill has come up with a really cool symbol for MVVM which I really like.

 

Slightly OT - you guys all know me well enough by now to move to the less formal Pete;->

--
Peter O'Hanlon

[Marlon Grech]

With Respect??????... I want to Kill Bill.... LOL hehe...

 

of course it is with respect... we are the disciples.... we are family :D

 

surprisingly I vote for MVVM :D

 

 

Bill.... I get your points on PresentationModel, yet I see MVVM going into much more detail and I would like to keep it that way... :) we should work on a project together sometime dude.... am sure we would have loads of fun :D 

 

hehe...

 

 

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Marlon Grech]

One thing is for sure... we would have a couple of fights over naming classes :D

hahaha

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Bill Kempf]

Well, a vote isn't really all that official, as this is a community thing, and not all of the community is represented here.  That said, I think between the P&P folks and the Disciples we have enough of the influential folks that if we all decided to do the same thing, the chances are the community would follow, even if slowly.  That's why I wanted discussion, but didn't ask for a vote :).

 

If we were to vote, I'm not sure where I'd land.  Because of historical reasons, I guess I'd lean towards "View Model AKA Presentation Model".  I'd prefer to drop the Model-View portion all together... I doubt you'd confuse anyone, and it just is a simpler name.

 

I do wish we'd stop referring to MVVM as a refinement of PM, though. That's simply not technically accurate. They are one and the same pattern, no matter what name you want to use. If that myth would stop being propagated, I'd have an easier time when talking with folks outside of the WPF circle.  If you mention PM in relation to MVVM, do so by explaining its an AKA, possibly giving the historical record of how they were independently "discovered" if you want to go into the details.  Certainly don't do what the recent MVVM Toolkit did, where they mentioned PM without explaining why it was mentioned or what relation it had to MVVM.

An aside about commands:  I didn't say it was a "minor" implementation detail, only that it was an important detail in the given context.  As for how you'd implement View Model using events, all you need to do is utilize events for the activity and a bindable property for the enabled state. The difficulty here lies in the lack of built-in support for hooking events to any handlers other than those in the codebehind (something MS should fix), but there's numerous ways to work around this (see Caliburn for one solution). There's certainly benefits to bundling these concepts into a single concept/interface, but it's not necessary.  For that matter, it's not even necessary to use events... a more traditional subject/observer pattern could work as well here, which is closer to what is done in Java (though they call their pattern an event, just to confuse ya ;).  All of these are implementation details that aren't really relevant to the pattern.  Please note, though, that I'm not suggesting that the ICommand isn't very important when discussing this pattern in relation to implementing it in WPF.

[Bill Kempf]

Ahhh... maybe not.  I hate the name game, and generally let others make the final decision.  I'm an opinionated SOB, so I'll make some remarks during the initial discussion, but once it comes time to pick, I'll generally just sit back and go with what someone else decides. :)

 

Heck, even in this case, if the community decides it's MVVM, I'll say MVVM.  Well, once, and then I'll refer to it as Poo for the rest of the conversation ;). Or, at least, as View Model.  In anything even semi-formal, I'll probably also go into the historical diatribe explaining this is AKA Presentation Model.  The need to explain will annoy me, but I'm not certain the need would go away now even if everyone decided to call it PM.

 

And honestly, Marlon, I don't mean any disrespect.  If you prefer MVVM, I'm more than OK with that.  If you insist on calling it a refinement of PM, maybe I'll have to hit you over the head with a club, but it will be done with all due respect ;).

[Jaime Rodriguez]

Adding Ivo for the toolkit feedback…    Again, the current toolkit was a 0.1 by the WPF test team, please hold off until 0.5 so you get a comprehensive view beyond that team.

 

Fully agree that M-V-VM and  PM are the same..   { on our MVVM training we use Fowler’s diagram; you can see deck from my blog }..  

 

Agree that Microsoft also needs to solve the “event to viewmodel” hookup ..   It is something being evaluated a lot, unfortunately it did not make the current release.. 

 

Cheers,

[Marlon Grech]

Hit me... haha

 

I get the point.... it's just that when I say ViewModel... bammm my brain says WPF.... if I say PresentationModel then I say mmm not sure....

mind you once I had a blog post where I implemented PresentationModel... I must find that one and show it to you....

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[John Gossman]

What is the cost of changing the terminology from MVVM to PresentationModel?  When people want to learn about ViewModel's I presume they use the trusty search engines to find what has been written already.  Using BrandX I get 79800 hits on the term PresentationModel and 1.2 million on ViewModel.  Who's going to update all the links?

[Josh Smith]

Can't we get an intern to do that?  :-)

[John Gossman]

btw -- "Presentation Model" gets 37 million hits.  "View Model" gets 260 million hits.  "Model View ViewModel" gets 231000 hits, "MVVM" gets 186000 hits.  Since the last is also the speed of light in miles-per-second, I vote for MVVM.

[Josh Smith]

> "MVVM" gets 186000 hits.  Since the last is also the speed of light in miles-per-second, I vote for MVVM.

 

Sound reasoning.  +1

[David Anson]

Hello? Metric System for the win! I, for one, welcome our new "Model View ViewModel" overlords.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: Tuesday, May 05, 2009 3:53 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: A Rose by any other name...

 

> "MVVM" gets 186000 hits.  Since the last is also the speed of light in miles-per-second, I vote for MVVM.

[Jeremiah Morrill]

All your View Models are belong to us.  

My 2c from the peanut gallery. 

What is the cost of changing the terminology from MVVM to PresentationModel?  When people want to learn about ViewModel's I presume they use the trusty search engines to find what has been written already.  Using BrandX I get 79800 hits on the term PresentationModel and 1.2 million on ViewModel.  Who's going to update all the links? <image001.gif>

 

 

 

[Josh Smith]

All your ModelViews are belong to us.

[Jeremiah Morrill]

LOL.  Who is going to tell our VM overloads someone changed their name?  Any volunteers?