> Yes, patterns are guidelines more than rules. I followed that discussion
> with very much interest and can't wait to try some of that in my next app,
> and it's really interesting to see the different streams of thoughts. So far
> I think I see two major variations in the exposed practices, one which
> considers that VM is a kind of replacement for code-behind (let's call it a
> top-down approach) and thus a VM is very tightly bound to a View. The other
> is rather a bottom-up approach and puts the VM as an extension of the model,
> but formatted for the View.

> In the project I worked last, we took a very pragmatic approach, and used VM
> for various reasons, the most important being avoiding that our designers
> have to write any code. Josh's point is really valid, designers should not
> have to worry about code, period. It's not their job. My role as an
> integrator (IM calls that "Interactive Developer") was to specifically avoid
> designers to have that kind of problems. This results in a series of
> roundtrips between developers and designers coordinated by the integrator.
> In that sense, a well thought VM can avoid a number of roundtrips. To me,
> this is the most important aspect of the VM, because every roundtrip costs a
> lot of money, and designers are damn expensive in a project.

> When I say we were pragmatic, I mean that because some in the team were
> quite unexperienced, we ended up having quite some code in the code-behind.
> If I had to do it again today, I would probably be stricter about that. But
> on the other hand, I saw another team take a much stricter approach (Josh:
> That was Linus' team, you probably remember him from our memorable dinner in
> NY) and they spent a lot more time on some details than we did. Also, some
> of the development was done in India, and their strict approach cost quite a
> lot of time round tripping between India and Switzerland, or worse, having
> to refactor much of the code that the Indian team delivered.

> Anyway… my next project should be a much smaller one (Silverlight), and I
> want to apply MVVM in a stricter way there. That should be interesting J

> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com]
> On Behalf Of Josh Smith
> Sent: Monday, December 01, 2008 9:03 PM

> To: wpf-disciples@googlegroups.com
> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for
> ValueConverters

> Suppose you're working in the designer-developer workflow.  Should the
> designers have to write the value converters?  What if they don't know how
> to write some of them?  I think it's easier to have the VM expose the
> properties that they need to bind against, instead of having the designers
> ask the developers to write a bunch of one-off converters for them.

> At the end of the day, MVVM (like any other pattern) is a set of guidelines,
> not rules.  So, as long as using the pattern makes your application better,
> development easier, and testing more thorough, it's all good.

> Josh

> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com>
> wrote:

> I'm with Marlon on this, while I agree that the VM can eliminate all
> converters  I don't like the idea of having a ViewModel too tied to the view
> and, after all, converters are very reusable J.

> Just had a look at Silverlight validation model, think there's a lot of work
> to do to fit it in a M-V-VM environment…

> -Corrado

> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com]
> On Behalf Of Marlon Grech
> Sent: lunedì 1 dicembre 2008 20:16

> To: wpf-disciples@googlegroups.com
> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for
> ValueConverters

> I also think that this should be 50% 50%... If there is something strongly
> UI coupled then I would probably put it in a ValueConverter...

> yet I must say I hate those creatures so called IValueConverters :/

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

> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> wrote:

> A ViewModel is basically a value converter on steroids.  I takes "raw" data
> and converts it into something presentation-friendly, and vice-versa.  If
> you ever find yourself binding an element's property to a ViewModel's
> property, and you're using a value converter, stop!  Why not just create a
> property on the ViewModel that exposes the "formatted" data, and then drop
> the value converter altogether?

> The only place I can see a use for value converters in an MVVM architecture
> is cross-element bindings.  If I'm binding the Visibility of a panel to the
> IsChecked of a CheckBox, then I will need to use the
> BooleanToVisibilityConverter.  But, perhaps even in that case I should take
> the "high road" and bind the IsChecked to a property on the ViewModel, and
> then have a SomePanelVisibility property on the VM, to which the Panel is
> bound.

> Do you agree???