Updated for SL4 here: http://www.scottlogic.co.uk/blog/colin/2010/05/silverlight-multibinding-solution-for-silverlight-4/

Regards, Colin E.

System.ArgumentException: Object of type ‘System.Windows.Data.Binding’ cannot be converted to type ‘System.Collections.ObjectModel.ObservableCollection

Thanks for your comments – I guess as you have discovered for yourself, it was Josh Smith who suggested that the MVVM pattern can be used to totally remove the need for ValueConverters. This is quite an extreme view and I think Josh proposed it in order to stimulate discussion. It has certainly done the trick!

I take a pragmatic approach and will quite often do away with MVVM altogether. WPF / Silverlight has a great binding framework that makes it possible to bind straight to your business objects. If you do not need unit test or designer support, then why use MVVM. I have mentioned this in some of my other posts:

http://www.scottlogic.co.uk/blog/colin/2009/08/the-mini-viewmodel-pattern/

I like the quote from Paul Stovell which you included.

Colin E.

First of all, I see this is a big contentious issue, which is sort of hanging in the balance still it seems (maybe Microsofts concreting their implementation of MVVM in 2010 will help).

After reading more of the discussions, I see what Josh Smith suggests is Model-ModelView-View-ViewModel (MMVVVM)
http://joshsmithonwpf.wordpress.com/2008/12/01/the-philosophies-of-mvvm
Horrible name yes, but provides some clarity as to what some view MVVM should be, which I previously pondered.

Essentially what I use are ModelViews, and I use converters instead of ViewModels for formatting etc. I’m still not sold on ViewModels as Josh describes, feel like you code-base will start to be very bloated. Yes, the formatting code is common to the converter and ViewModel, I just feel creating a new ViewModel class with new properties is a bit much, adding another level (think about adding a new property to your Model, bubbling up (or down) you have another layer to add it to?
I will refer to mine as VMs (basically combines Models for a View), and Josh’s as ViewModel and ModelView, to try prevent some confusion.

Typically I have a VM per View (i.e. per Control), which exposes a number of Models. Converters convert the Model properties to a desired format, based on a preferences manager say. If I had multiple Views for a specific VM, I would control the formatting by the converter and the preferences, as opposed to having multiple ViewModels for each. That would lead to having a ModelView per Model, a ViewModel for each Model and View, and another ViewModel per View (which combines the ViewModels per Model & View for each Control)? All a bit confusing…

As others Paul Stovell said, “I see the VM as a way of shaping the domain model, rather than a wayof completely simplifying the view.”
His example: “a library book is overdue, then I might expose a property such as ‘IsOverdue’ which my panel’s visibility is based on.”, and not have a Visibility property in the VM.

Thoughts?