There was a very long and interesting thread about MVVM today amongst the WPF Disciples. The thread started out with a simple thought: using a ViewModel eliminates most scenarios where value converters are necessary. My point was that a ViewModel class is essentially a value converter on steroids, thus rendering the IValueConverter interface irrelevant for most bindings.
This comment lead to a very engaging discussion about peoples’ fundamental philosophies regarding how a well-designed WPF application should be built. Some people strongly disagreed with me, and gave lucid explanations of why. It was a real eye-opener for me to have fellow MVVM advocates express opinions that, while completely valid and reasonable, are strikingly different from my own.
The thread even took a brief detour into something I’ve been thinking about for a while now but never publicly discussed: MMVVVVM! Yeah, I know, that’s a terrible name for a design pattern…
If this sort of thing interests you, I highly suggest you set aside some time to read this thread. What are your thoughts about this?
Josh Smith on WPF 
Hi Josh,
I believe the whole debate is something for purists. I think the question if to use of converters or not has minimal impact on the pattern and besides that is far less important than other questions we (you) still dont seem to have an answer for.
If you want to really help the community at least in my opinion try to let more light of wisdom shine on the whole commanding area. I know you debated that a lot among each other but it does not led into some concrete direction. To me there is even more confusion what to use and what not. RoutedCommands, DelegateCommands, your CommandSink Solution, simple ICommand whathaveyou….
Another big thing is the lack of an overview of the pattern other that there is such a thing called viewmodel (aka poo) on top of our data what the view can bind to.
But who is constructing what and when …who holds references to what…the view the viewmodel the viewmodel the view…..
What if the example gets more complicated than one bound listbox and a button which is enabled or disabled based on selection in the listbox…..what if there are multiple views and viewmodels? How do they interact? Where (in what viewmodel) are commands living not specific for a single view? the list goes on and on….. 🙂
To sum up: those question i believe influence the pattern far more than if you would use a converter from time to time for convenience.
Regards
Nick
Nick,
I don’t blog, write articles, etc. to help the community (you). I do it for fun and professional reasons. If others happen to find my content useful or educational, that’s great, but that’s not the point. I see no benefit in your comment, aside from perhaps you taking the opportunity to vent your frustration at the lack of guidance from *Microsoft* on how to use *their* platform. There’s no good reason to blame me for not explaining every last detail about how to create WPF applications.
I agree that the issues you listed are important. It’s odd you assume that because I’ve never written about them, that I “still don’t seem to have an answer for” them. Have an answer for whom? Perhaps you should start a blog and start writing about these things too. Trust me, writing about topics really helps you to think them through and find good answers. 😉
Josh
Very interesting thread.
I think I would take a more pragmatic path:
You have a model, you have a view, and anything in between is ViewModel.
Whether you classify it as a reusable view friendly model state, or view specific classes (more like a code behind) is just the degree of reuse you design and evolve as you add more views and your applications grow.
To Nick’s point, I think we need more guidance on this. P&P probably isn’t good enough – I would look to better tooling. I think tools really drive design patterns for the everyday, solution oriented programmer. If the IDE team could provide some visual dependency management and a visual ViewModel designer it would go a long way to making declarative model driven UI more natural.
Joe
Great points, Joe! I agree that the reusability aspect of the VM/MV classes is something that would evolve as an application grows. In particular the “ModelView” classes (i.e. presentation-friendly wrappers around data objects) would be the real sticking point, with regards to reuse and extensibility.
I completely agree about the tooling support. I’ve actually had this discussion with folks from the WPF team at MSFT, and other WPF fanatics. Most people agree that this is a great idea, but just imagine the enormous backlog the Cider team faces at this point, and the timeframe for such a feature becomes less and less appealing.
Josh
Josh,
…reading your respondse seems that i have missed the tone somehow or didnt bring across what i was trying to say….my comment shouldnt be offensive in any way…shame on me if it sounded like it…maybe it was due to that english is not my mother language….quite the opposite is the case…i highly respect your opinions and admire your engagement with WPF…so hope thats out of the way…
…the only thing i was trying to get across is…i would love to encourage you and your disciple friends as i consider smarter than i and i guess perhaps many other people working with WPF to “shine more light of your wisdom” on subjects that bother a lot….and yes, knowing that you dont have to you still would do i think the community a big favor because i think those riddles makes WPF unfortunately very difficult to understand and use…i would love to solve it but i am unfortunately not experienced enough…and yes it is somewhat frustrating that i am begging you to step in for what MS has in my opinion failed to explain so far…
…so once more i hope you see me asking for guidance rather as a sign of respect for you than a blame or anything like it…
Nick
Nick,
Thanks for clearing that up! 😀
One other thing…If you want to see MVVM in use in a real app, not just a simple demo, then definitely check out the source code to Crack.NET. Several people have told me that they think Crack.NET is probably the best example of MVVM out there so far. Not to blow my own bubble…
http://www.codeplex.com/cracknetproject/SourceControl/ListDownloadableCommits.aspx
Josh
Hi Josh,
I’ve resd thru some of your works. Great! I have been working on apps based on WPF for the past 1 year. Really fantastic. I got some issues regarding the RichTextBox control. I tried to search for your email address on this site but couldn’t find it. Is there any way I can share the issues I face with so that you can give some insights into how to solve them? Can you provide me your email address? or Shud I leave it as a comment in one of your posts?
Karthik
[…] Josh Smith expresses The Philosophies of MVVM […]
Thought provoking as always Josh. I really must join the disciples if this is the level of discussion that goes on in there.
Anyway – my take on MVVM. An area that I’ve mentioned to you in the past, is being able to ship new views to spice up an application. Now, this is an area that I’ve been playing round with – using Dependency Injection to inject views into applications. By implementing a clean separation with MVVM, it makes this injection a lot easier to perform, and that’s great for the profit margins.
Josh – Sorry if I appear to be stepping on toes here, but I’d like to answer this one for Karthik.
Karthik – Josh is one of the most respected figures in the WPF world, and he wouldn’t have time to sleep, eat or bathe if he provided help for everybody who requests it. He isn’t a private resource that you can draw on at will. Please, respect what Josh does for the community and respect yourself – learn from the same resources we have all used.
Thanks Pete. 8)
Josh,
I completely disagree with how you initially framed MVVM versus View components that contain ValueConverter objects.
However, I think later on in the thread you put together some questions that most people ask. My co-workers ask me similar questions. As you pointed out, this topic can be distilled into the following extreme questions:
Why bother with a ViewModel at all?
Why not just bind directly to the Model and use Value Converters to handle all other transformations that need to be applied to make the Model show up in the UI correctly?
First, WPF is primarily a GUI toolkit for rich user interfaces, and that means it provides a lot of capability for prototyping new user interface concepts. Jensen Harris said at MIX ’08 that he told the programmers of Office that the code had to accomodate significant changes in UI with six months to ship. Tying everything to a single ViewModel, or even multiple ViewModels of the same Model, would make the application harder to understand.
Second, if you use only a ViewModel, then you are effectively creating a one-time policy accord that says the model will only have one view. ValueConverter objects in the view allow for data shaping, as do many other WPF Data Binding-related features.
Lastly, you’re arguing about artificial complexity, not essential complexity. See the forest for the trees. The core requirement is having a good way to delete-and-insert a new view when the underlying model’s data dictionary changes.
I do agree that the “sweet balance” depends on a lot of factors, though. This is what makes giving advice to others difficult for me. My balancing strategies are specific to my domain.
Sorry about that…I’ve posted it in the msdn forums. I didn’t mean to disrespect anyone here.
It is a very interesting thread indeed. Here are my two cents …
Firstly, I dislike complexity, and particularly dislike shunting data between one model and another. Very recently I was working with the WPF DataGrid binding it to a DataTable (very old-skool!). I wanted to style the rows based on the RowState, however this is not a dependency property or a property of a CLR property of an object with INotifyPropertyChanged, so change notification was a problem. I posted on the MSDN WPF Forums to see if anyone had a clever workaround. The response from Marco Zhou was to create a view-model.
With these two little words, the RAD development of binding a designer generated typed dataset to a WPF datagrid suddenly becomes a lot more complex, IDataErrorInfo, INotifyPropertyChanged, IEditableObject, ad nauseum.
My solution – be pragmmatic = code-behind.
My second thought – unit testing. How is a VM better for unit testing that a value converter? Also, unit testing is very fashionable right now, and yes, I follow that trend, however I would feel happier in a project which has good test coverage through automated functional testing on the real UI at runtime.
Anyhow, as I said, and interesting discussion.
One last thing, I am guessing that your train of thought has been heading in this direction from your previous blog post about improved validation errors, i.e. where you perform type conversion yourself in the VM, catching any errors that occur. I have expanded my ideas of an alternative a little further here:
Best Regards,
Colin E.
About the tools….
I understand that the team is busy. But I think the community could help here. Why not start an ‘official’ codeplex project for MVVM tools. I’m thinking something like a XAML powertools equivalent for WPF and SL. It could even include replacement classes for CollectionViewSource – maybe something more link Continuous Linq.
By ‘official’ I mean something that MS contributes to aswell as the community. Maybe the new extensibility model in VS2010 could be a good new platform for this.
I’d love that, Joe. Maybe after Crack.NET is “where I want it to be” I could help contribute to something like that.
Josh
Hello everyone,
I was hoping to contribute to the thread but it’s members only so I’ll post my ramblings here. If someone could post this on the thread on my behalf that would be great, I could use some feedback from the big brains out there. 😀
I’ve been a big fan of the MVVM pattern in WPF and have used it extensively in my projects. After reading this thread, I’ve come to appreciate the differing philosophies regarding whether the VM should be tightly integrated with the View or decoupled. I have to say that after reading this thread I agree more with Dr. WPF’s position as it has been the way I’ve been implementing my MVVM. However, I also agree with Josh that if it comes down to choosing to be a purist for purist’s sake or making the code more maintainable by putting in some heretic functionality in the VM, then I’m all for heresy though I do so gritting my teeth since it seems like a hack to me deep down inside. My VM is somewhat based on Dan Crevier’s pattern and incorporates Josh Smith’s excellent CommandBinding functionality… kudos to you guys for pioneering such great work. One of the biggest problems I’ve encountered using MVVM has been reacting to the user’s action via a command. For example, let’s say that I have a button bound to a VM’s command (Josh Smith’s implementation)… clicking this button should open a window. The problem is that if the user clicks the button and the command’s execute method is fired in the VM, the VM should be loosely coupled to the View and really should know nothing about the View, therefore the VM’s execute command cannot contain any code that directly opens any windows. So now I have to create an inderect method of telling the view “Hey, you need to respond to this action”… this way the View is in charge of knowing how to respond to this action, not the VM. This way you can have multiple Views that react differently to the underlying VM… one View that opens a window in response to this action, while another View makes a hidden panel visible instead. I currently have it so that my VM’s base class has an ActionExecuted event that gets fired whenever I need to notify the UI that something special is happening that needs to be handled, but I’m not really happy with this approach… it feels wrong. Does anyone have any thoughts on a general framework for this?
On a side note, I am planning on giving a little back to the community in a blog series that I’m writing which is basically a step-by-step tutorial on the MVVM pattern for beginner and intermediate programmers. If I could post my material to your group for reviewing/editing/constructive criticism before making it live I would appreciate it.
Regards,
Anthony
I need Help? i know that listview doesn’t support commanding by default, but i have a listview and would like to hookup command binding to it, so when i click on a row it fires the command and passes the selecteditem as a parameter.
Thanks
Hey Josh,
I’ve been following your articles on codeproject and here for a long time and i just wanna say keep up the good work! I read these comments and see you have a lot of demands you need to fulfill ;). I’m wondering, when you are free would you like to help me build my L.H.C. in WPF 🙂
Great Stuff
Would the use of partial classes as the model view in MVVM be good, bad or obsolete? Or How about utilizing the partial class of a Data Transfer Object created by SvcConfig or “Add Service Reference” in order to create a second linked partial class which implements IErrorDataInfo?
Thanks
Dan,
What benefits do you have in mind regarding the use of partial classes?
Josh
Thanks Adam. I’m glad that people find the output of my hobby so enjoyable. 🙂
Josh
Well … after racking my brain I can’t come up with a true benefit to using partial classes as MV, just lots of nonsense.
Again, Great Stuff though…. particularly the CommandSinkBinding example
My only other half baked attempt at a contribution to this discussion is … how this pattern should simplify developing applications which communicate with each other, possibly using WCFs Duplex pattern or an efficient implementation of WCFs P2P binding/pattern to synchronize/share/expose MV data or command information.
Thanks