New Blog Post on MVVM
Shawn Wildermuth
http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model
Tell me what you think….(as comments on the post would be great)
Thanks,
Shawn Wildermuth
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour is coming to a city near you!
Pavan Podila
Pavan Podila, MVP - Client App Dev
http://blog.pixelingene.com
------------------------------------------
Jaime Rodriguez
Shawn, here is my answer, let
me know if you want me to post it on your blog; it feels a bit long (and a bit
too blunt).. but I do feel it should be something your readers hear.
--------------
I respect the argument, agree with your solution, but found both your sample implementations misleading or lacking.
On your implementations,
On View-First, sorry but no real-world
app will use Resources collection to create a ViewModel.
There are so many other better implementations you could be using. [In
SL, an attached behavior to a factory, or in WPF, an x:Static to a
factory, a custom mark-up extension etc.].
Even writing one line of code in a View’s constructor is better than
resources.
Your view-model-first solution first looks simple; I liked it; but then you (possibly) mislead people by hinting you use an IOC. I hope people can read over that and realize that an IOC is absolutely not needed (been fighting that FUD a lot lately, Prism is a composite pattern implementation, if you want MVVM simply extract the pieces you need and ignore the rest).
Regarding the solution, I agree with yours. That is how I do it (in the simpler implementations). In our MVVM class I explain it the opposite; I say that the solution is a “divorce lawyer” who benefits the most from making sure the View and ViewModel can’t communicate or know anything about each other.
For the geeky architect types, in
my early training events, before you all implemented sample mediators, I used say
the solution was a Mediator (cause that is closest pattern I could find ) but
people lately have been getting confused because they have seen only message
based implementations of Mediator; the mediator pattern itself does not dictate
message based and IMO message-based does not work well (by itself) for large M-V-VM
apps so I am now resorting to calling it “man in the middle”
to avoid confusion (yes, I know that is not a pattern, but people get it).. I
am looking for a better name, that is why the long story here (in case anyone
has a better name).
Cheers!
PS – Actually one part
where we do deviate is that I do not like IVIew interface; or at least I do not
like the ViewModel knowing about the IView; it leads to
people using the interface as an excuse to hang other things from there. If
you must have an IView, let the ManIntheMiddle know about it, but not the
VM.
For simply setting DataContext, I go straight into the DataContext for the view.
The only times I use IView is when I need it for transitions.
Shawn Wildermuth
Good points all. When I teach MVVM, its before IoC and Prism so I teach it without it but I didn’t make that crystal clear in the post.
As far as IView is concerned, I understand your fear of hanging more data there, but the reason I want to use ApplyViewModel (or a method named something more generic) is that you may not be applying it to the DataContext of the view. It may be somewhere more specific so I want to let the view make that decision. Requiring it on the DataContext wasn’t necessarily in my mind as the View has a DataContext today, but this pattern should still work in other views outside of WPF/SL XAML.
Lastly, about the divorce attorney. Good nomenclature. But I think marriage works because as we all know, married couples don’t communicate ;)
Thanks,
Shawn Wildermuth
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour is coming to a city near you!
Laurent Bugnion
I am curious, a few times already you were quite vocal against creating the VM in Resources. I asked you before why you dislike it, but didn't see your reply. Do you care to elaborate? Is it because of perf, because you want to hide the VM creation more, or any other reason? Very curious.
The other options you list all have their disadvantage. First, i want a solution that works both in WPF and SL with the same syntax, which rules out markup extensions (which is a shame though). Then, i want to do as much work as i can in Blend, which speaks against attached behaviors.
I do understand that these reasons might seem not very important, but unless there is a clear reason against VM creation in resources, i think that this way does make sense.
By the way, i have used it in various 'real life' applications :)
Looking forward to your answers.
Cheers,
Laurent
--
Sent from mobile
-original message-
Subject: [WPF Disciples] Re: New Blog Post on MVVM
From: Jaime Rodriguez <jai...@microsoft.com>
Date: 23.05.2009 05:22
Shawn, here is my answer, let me know if you want me to post it on your blog; it feels a bit long (and a bit too blunt).. but I do feel it should be something your readers hear.
--------------
I respect the argument, agree with your solution, but found both your sample implementations misleading or lacking.
On your implementations,
On View-First, sorry but no real-world app will use Resources collection to create a ViewModel.
There are so many other better implementations you could be using. [In SL, an attached behavior to a factory, or in WPF, an x:Static to a factory, a custom mark-up extension etc.].
Even writing one line of code in a View's constructor is better than resources.
Your view-model-first solution first looks simple; I liked it; but then you (possibly) mislead people by hinting you use an IOC. I hope people can read over that and realize that an IOC is absolutely not needed (been fighting that FUD a lot lately, Prism is a composite pattern implementation, if you want MVVM simply extract the pieces you need and ignore the rest).
Regarding the solution, I agree with yours. That is how I do it (in the simpler implementations). In our MVVM class I explain it the opposite; I say that the solution is a "divorce lawyer" who benefits the most from making sure the View and ViewModel can't communicate or know anything about each other.
For the geeky architect types, in my early training events, before you all implemented sample mediators, I used say the solution was a Mediator (cause that is closest pattern I could find ) but people lately have been getting confused because they have seen only message based implementations of Mediator; the mediator pattern itself does not dictate message based and IMO message-based does not work well (by itself) for large M-V-VM apps so I am now resorting to calling it "man in the middle" to avoid confusion (yes, I know that is not a pattern, but people get it).. I am looking for a better name, that is why the long story here (in case anyone has a better name).
Cheers!
PS - Actually one part where we do deviate is that I do not like IVIew interface; or at least I do not like the ViewModel knowing about the IView; it leads to people using the interface as an excuse to hang other things from there. If you must have an IView, let the ManIntheMiddle know about it, but not the VM.
For simply setting DataContext, I go straight into the DataContext for the view. The only times I use IView is when I need it for transitions.
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Shawn Wildermuth
Sent: Friday, May 22, 2009 7:14 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] New Blog Post on MVVM
http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model
Tell me what you think....(as comments on the post would be great)
Thanks,
Shawn Wildermuth
http://wildermuth.com<http://wildermuth.com/>
https://agilitrain.com<https://agilitrain.com/>
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour<http://www.silverlight-tour.com/> is coming to a city near you!
Jaime Rodriguez
Sorry if I came too strong; the problem is one of you uses it for a demo (to simplify a post) and then there is 50 people who try to use it in production; I have been seeing too much of that lately during our trainings.
A few of my reasons against viewmodel in Resources (in random order)
I like to avoid code-behind in Blend unless it is safely wrapped; straight creation of resources the way shawn demonstrated (I am guessing to simplify the example) don't give me that flexibility. Attached behaviors gives me that flexibility.
I like to have control over when VMs are created; I hardly ever let it go beyond a View's constructor because I need to manage life-time of the view. Leaving it to resources collection feel non-deterministic; I am sure you know that WPF and SL behave different when it comes to instantiation of resources.
I like for View to be decoupled from the ViewModel; having the view's resources collection hold a static reference to the type of the viewmodel is not decoupled enough for me.
I have been known to overshare and compose nested viewmodels within my app (to avoid any round trips to get data), so the concept of a view creating its view model after creation is very unusual to me.
Putting loose content into a property bag that someone can override any time, seems wrong. I have seen people who don't merge resources the right ways and then override their own properties. I am not as comfortable with it.
I think the Resources collection is fair game for designers; I rather keep as much as I can out of it. In other words, for me, resources is View (and it should stay as such). I also do not like commands in the resources collection.
I do not like to create even design-time data that calls webservices, or databases; it slows down blend because blend reloads and recreates the views a lot (as you recompile or make changes); So having a reference to real-data within the view follows that same problem. And to be honest, I have never gotten the getting the external data to work well within blend, in particular in a scenario that worked well in Sivlerlight and WPF; there are significant differences in the run-times at design-time.
I do know not all applications connect to external data, so I do not doubt you could have created a real-world app without it, for context, when I use the term real-world, I usually refer to enterprise scale apps; so I was averaging towards most apps having external data.
---
Last time you asked was in the context of design-time data, there is a post here
http://blogs.msdn.com/jaimer/archive/2009/02/20/design-time-data-in-blend.aspx, I agree that we did not close on it last time, why do you think attached behaviors is a disadvantage in Blend?
Laurent Bugnion [MVP, MCP]
No worries at all about sounding passionate, this is a great motivation for me to learn from the best guys in the industry.
What you say makes sense, and I need a little time to think about it. I will reply more in detail later.
The reason why I have been using creation in resources is because so far I honestly thought it was the best answer to the particular set of requirements I had, but I am always ready and eager to reconsider and find a better way. For the moment, the attached behavior solution seems the best from what you propose, and I want to play with this a little more. As you know, I am working on a MVVM light framework, and on some samples too, and I want to get it right. Unfortunately, I am very very busy with some projects right now, so not much time to work on that, but it is always on my mind :)
Cheers,
Laurent