Thought: MVVM eliminates 99% of the need for ValueConverters

13,770 views
Skip to first unread message

Josh Smith

unread,
Dec 1, 2008, 11:08:47 AM12/1/08
to wpf-di...@googlegroups.com
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???

Laurent Bugnion, GalaSoft [MVP]

unread,
Dec 1, 2008, 11:11:43 AM12/1/08
to wpf-di...@googlegroups.com

This is how I see things too. Note that in Silverlight, you cannot bind to ElementName (yet) so the high road is the only road available ;)

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.12/1822 - Release Date: 12/1/2008 8:23 AM

Karl Shifflett

unread,
Dec 1, 2008, 11:23:14 AM12/1/08
to wpf-di...@googlegroups.com
Josh,

I'm onboard.

The other exception is when you need to implement a ForceReReadConverter to force the WPF Data Binding engine to requery the property it just changed.

Example: The business object has built in rules that can alter the case of the inputted entry. When the business object alters the case of the inputted text, it does raise the PropertyChanged event, which WPF ignores. So... in order to get the data binding engine to reread the value from the business object, you have to have a converter in place, this will cause the data binding pipeline to reread the value. Works great. Wish we didn't have to do this, but we do.

Karl

________________________________

From: wpf-di...@googlegroups.com on behalf of Josh Smith
Sent: Mon 12/1/2008 8:08 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Thought: MVVM eliminates 99% of the need for ValueConverters

winmail.dat

Paul Stovell

unread,
Dec 1, 2008, 11:21:07 AM12/1/08
to wpf-di...@googlegroups.com
If I'm not mistaken, I believe we created these patterns so we'd stop mixing UI logic code with logic code :-) Is the VM going to become The Next CodeBehind?

To put it another way, I think it risks mixing concerns. If I'm browsing the VM following the process for downloading the file and communicating whether it's done, I'd rather not see the code adding "%" after each number or an IsCancelButtonEnabled property. I'd much rather a ProgressPercentage integer property and a HasCompleted boolean property, and let the view convert it. The VM manages state, the view manages how it's visualized.

I think of the "state" of my VM as the conceptual state, not the real state. It's kind of like the difference between the Logical tree and the Visual tree, but at a domain level.
--
Paul Stovell
http://www.paulstovell.net

Bill Kempf

unread,
Dec 1, 2008, 11:22:14 AM12/1/08
to wpf-di...@googlegroups.com
Yes... and no. I think that if you're reaching for a value converter,
you do need to stop and think, because it's often simpler, cleaner and
easier to maintain to just use a special property on the view model.
However, there's reasons beyond the ones you've given to not go for a
special property.

1. If the value you need is unique to presentation, you should
consider still using a converter. Visibility is a classic example.
If one of your reasons to be using MVPoo is to be able to use multiple
presentation frameworks (WPF, WinForms, WebForms, ASP.NET MVC, etc.)
then the last thing you want to do is expose a property of type
Visibility. Even if you're sticking to WPF, there's two possible
"hidden" values with differing characteristics (hidden and collapsed).
Choosing among these is a view concern, not a view model concern.
(It actually bugs me that the BooleanToVisibilityConverter doesn't
support this choice out of the box!)

2. Formatting is generally a presentation concern, and should be
handled by the view. It may be tempting to add a property that
formats that date in some specific way, but down the road when you use
a different view that wants to format that date in another way, you
have friction between views that may not be easily resolved. Again,
if the conversion is to facilitate presentation, let the view handle
it.

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

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

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

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

Josh Smith

unread,
Dec 1, 2008, 11:33:36 AM12/1/08
to wpf-di...@googlegroups.com
Paul,

I see what you mean.  I don't see my suggestion as promoting the ViewModel as the next code-behind, though.  The code-behind of a View still serves a purpose in MVVM, aside from what the VM does.  For example, I would never create a property in a code-behind and then bind an element's property to it. To me, the state of the UI includes the state of the functional areas in the UI, such as whether some panel is open or closed.  In my way of thinking, that state belongs in the ViewModel.

Josh

Josh Smith

unread,
Dec 1, 2008, 11:40:47 AM12/1/08
to wpf-di...@googlegroups.com
Bill,

You're right about the multiple frameworks argument, but that's not my goal, so I didn't factor it into my thought.  To be honest, I'd be very interested in seeing someone actually reuse a set of ViewModel classes in WinForms, ASP.NET, and WPF.  I'd be happy enough just to see someone reuse them in WPF and SL.  :)

Your point about "friction" between multiple Views raises a long-standing issue of mine.  I think the terminology of MVVM is too limited.  Really that pattern should be Model-ModelView-View-ViewModel (MMVVVM).  The distiction between ModelView and ViewModel is the important point here.  I've found that many times I create a VM for a model object, such as CustomerViewModel for Customer.  I also create a ViewModel for a View object, such as CustomerViewModel for CustomerView.  The friction you described is particular to the former case, where a "view model" is created for a model object, but not for one particular View.  This is a sore point in the MVVM world.

I think that it is better to call a presentation-friendly wrapper around a Model object by its proper name: a ModelView.  So, if I have a Customer class and want to make it easy to show an instance via binding in WPF, I should have a CustomerModelView class.  If I have an input form that shows a new Customer, I should create an abstraction of that View, called CustomerViewModel.  This way, the CustomerViewModel would perform the View-specific formatting, since it wouldn't be reused anywhere.  However, the CustomerModelView could be shared across multiple Views and ViewModels.

Josh

Paul Stovell

unread,
Dec 1, 2008, 11:55:29 AM12/1/08
to wpf-di...@googlegroups.com
>> For example, I would never create a property in a code-behind and then bind an element's property to it.

So, I actually don't see a problem with that. Sometimes code-behind is a perfectly adequate view model. Especially if that property is very UI specific, such as whether a panel is collapsed.

I guess the way I think about it is the state of the UI is different to the state of the information making up the UI. A panel being open/closed is very UI-specific, in my books, so I probably wouldn't include it. If it was based on some information however - like whether a library book is overdue, then I might expose a property such as "IsOverdue" which my panel's visibility is based on. This comes down to how I want to seperate concerns - I want to know whether George remembered to check whether the book was on hold before making it available to borrow; not how he surfaced that in the UI.

I guess I see the VM as a way of shaping the domain model, rather than a way of completely simplifying the view.

Paul Stovell

unread,
Dec 1, 2008, 12:04:40 PM12/1/08
to wpf-di...@googlegroups.com
Hi Josh,

I'm interested in this scenario:


>> So, if I have a Customer class and want to make it easy to show an instance via binding in WPF, I should have a CustomerModelView class.  If I have an input form that shows a new Customer, I should create an abstraction of that View, called CustomerViewModel.  This way, the CustomerViewModel would perform the View-specific formatting, since it wouldn't be reused anywhere.  However, the CustomerModelView could be shared across multiple Views and ViewModels.

Can you explain this in more detail? What kinds of properties/behavior/logic would you see on each class?

Perhaps we could have a "disciples code off" to see each person's approach.

Paul

Josh Smith

unread,
Dec 1, 2008, 12:05:00 PM12/1/08
to wpf-di...@googlegroups.com
>> I guess I see the VM as a way of shaping the domain model, rather than a way of completely simplifying the view.

Extracting the behavior of a View into a ViewModel does more than simplify the View.  I find that it makes it much easier to write unit tests that "pretend" to be the View.  The tests become simply another consumer of the ViewModel, which allows them to help ensure that the UI will behave as expected, without ever having to deal with the added complexities of testing live visual elements. 

Deciding how smart the various pieces of a system should be boils down to personal preference and philosophy.  I can definitely see the benefits of offloading lots of View-oriented logic into value converters, or the code-behind, as you encourage.  I simply find value converters to be hacky and mysterious.  They are an anti-pattern, in my opinion.

Isn't it great that WPF is so flexible that we can have these discussions?!

Josh

Paul Stovell

unread,
Dec 1, 2008, 12:09:28 PM12/1/08
to wpf-di...@googlegroups.com
>> Isn't it great that WPF is so flexible that we can have these discussions?!

Amen.

In Windows Forms we'd be busily overriding the paint event of a custom data grid view column without converters :)

Josh Smith

unread,
Dec 1, 2008, 12:11:16 PM12/1/08
to wpf-di...@googlegroups.com
Sure thing.

Suppose the Customer class exposes each value as a getXYZ() method.  The CustomerModelView (CMV) would then wrap each of them into a property.  The CustomerViewModel (CMV) would be responsible for putting all the CMVs into an observable collection, provide aggregation values (i.e. total sales, etc) and CustomerView (CV) would be responsible for showing them all in a sexy WPF-ified way.  :)

Suppose Customer has properties, not methods, but many of them store indici which can be used to retrieve values by look-up form other objects.  The CMV would expose properties that internally perform the lookups. 

Suppose Customer has validation logic that throws exceptions if a property is set to an invalid value.  CMV would catch those exceptions and implement IDataErrorInfo to provide a soft, clean form of object validation.

In each of these situations, the ModelView (not the ViewModel) acts as a ViewModel-agnostic adapter around a Model object. 

Josh

Paul Stovell

unread,
Dec 1, 2008, 12:22:16 PM12/1/08
to wpf-di...@googlegroups.com
As a general pattern, I'd say the ModelView is really just another part of the model - it just happens to be derived or adapting an existing object, but it may not always be. If you refactored it later to remove the messy Customer class, your ModelView might not make so much sense. In a similar situation, if my objects were based on DataRows in a legacy DataSet, I'd consider both the DS and the objects as part of the model. Perhaps just "CustomerAdapter"?

For a specific problem like that, for adapters, I always think of TypeDescriptor Providers. It would be trivial to build a very generic adapter to turn those methods into properties and exceptions into IDataErrorInfo, and you'd only code it once.

Josh Smith

unread,
Dec 1, 2008, 12:47:09 PM12/1/08
to wpf-di...@googlegroups.com
I'm not familiar with TypeDescriptor Providers, I will have to check that out.  I agree that ideally you should refactor those "difficult" Model classes, but that's not always an option.  Many times, especially in large companies, Model classes are inherited from other systems or the new system's predecessor, and cannot be modified. 

Josh

Mike Brown

unread,
Dec 1, 2008, 1:59:36 PM12/1/08
to wpf-di...@googlegroups.com
TypeDescriptor Providers are in-friggin-credible. I use them to create bindable property bags. But I also discovered that you can use an adapter to front an object as a dependency object and dynamically generate dependency properties to provide the same effect. And because dependency properties work with the binding system, they even work in non-wpf scenarios. I have a nagging suspicion that under the hood, dependency properties use the TypeDescriptor system. Wrote a quick blurb about it here. Never got around to sanitizing the code before leaving the last place :P

Mike Brown

unread,
Dec 1, 2008, 2:00:26 PM12/1/08
to wpf-di...@googlegroups.com
We created a fully metadata driven UI using this approach BTW.

Marlon Grech

unread,
Dec 1, 2008, 2:15:37 PM12/1/08
to wpf-di...@googlegroups.com
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/

Jaime Rodriguez

unread,
Dec 1, 2008, 2:41:00 PM12/1/08
to wpf-di...@googlegroups.com

wow..    you all folks think (and email) faster than I can read  : ) …. So I apologize for keeping the thread alive ( specially life cycle) if you had all moved on..

 

 

 

1)      On avoiding ValueConverters when you have a ViewModel …   I agree with Bill …  Value Converters are OK for me (some times).    Imo, ViewModel has logic and  if it makes it readable to use Booleans instead of Visibility,  I do it..   I try to keep ViewModel agnostic of presentation details like visibility, and ValueConverters does this nicely..   

a.       I am also a TypeDecriptorProvider virgin so I need to learn more about it…  

2)      On the “life cycle” of ViewModel (and Initialize method) …    I would love to better understand the decomposition of your lifecycle..   Does anyone have a hardcore rule?

a.       When is the data fetched?

b.      When are Commands wired and exposed??

c.       Does the ViewModel wire up for Loaded ??  I kind of read on that….    Or  Does the ViewModel implement an Interface that the view calls??    ( I opted for the latter the few times I did this, it is interface driven so generic) ..

d.      Dispose () on a view model  is new to me ….  Never needed it before…   what kind of scenarios need it??

My experience:

I hate thick constructors and I hate to delay Views… but  a common gotcha for me is that if I  wire up a DataContext to a form and it has not been fully initialized, then my Commands either do two or three times as much work (if I wire them after initialization) or can get into funny states where a command’s CanExecute logic returns wrong result just because proper state was not ready…     

If any one can share their  practices on Initialize () of a ViewModel  I would love to know more about the logical and consistent approach…     

 

                       [Yes,  the issues below have easy workarounds….     I am just trying to better read pros & cons to other’s experiences J ]. .

 

Thanks..

 

 

 

 

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith


Sent: Monday, December 01, 2008 9:47 AM
To: wpf-di...@googlegroups.com

Josh Smith

unread,
Dec 1, 2008, 2:50:44 PM12/1/08
to wpf-di...@googlegroups.com
Jaime,

Good threads never die, nor should they. :)


>> a.       When is the data fetched?

I have no hard-and-fast rule for this.  Usually, data should be fetched when it's needed, unless you're talking about a huge amount of static data that might need to be pre-loaded and cached.  Karl raised a good point the other day during one of our marathon phone calls that in a multi-user system, data should be retrieved delayed and performed as frequently as possible because a record could become stale while sitting on the client.


>> b.      When are Commands wired and exposed??

In my book, commands are exposed by ViewModel objects as properties.  They are wired to command sources (i.e. Buttons) via data binding when a View is loaded.


>> c.       Does the ViewModel wire up for Loaded ??  I kind of read on that….    Or  Does the ViewModel implement an Interface that the view calls??    ( I opted for the latter the few times I did this, it is interface driven so generic) ..

In my book, no way.  My Views are created via the magic of typed datatemplate resolution, in response to a ViewModel object trying to be "shown" in the UI.  My VM objects have their Initialize method invoked at the time that they are put into the UI...which means when they are added to the "live" VM object graph. 

>> d.      Dispose () on a view model  is new to me ….  Never needed it before…   what kind of scenarios need it??

Profile your MVVM apps and you might find you have some memory leaks.  I sure did.  The problem was that my VM objects were hooking events on objects that live longer than they do, but never unhooking the event.  I have a Dispose method on my VM base class, so that subclasses can override a virtual OnDispose() and unhook the handlers, to ensure proper garbage collection.

Josh

Corrado Cavalli

unread,
Dec 1, 2008, 2:54:04 PM12/1/08
to wpf-di...@googlegroups.com

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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Marlon Grech
Sent: lunedì 1 dicembre 2008 20:16
To: wpf-di...@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 <flappl...@gmail.com> wrote:

Josh Smith

unread,
Dec 1, 2008, 3:02:33 PM12/1/08
to wpf-di...@googlegroups.com
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

Bill Kempf

unread,
Dec 1, 2008, 3:31:08 PM12/1/08
to wpf-di...@googlegroups.com
If it's a "one-off" converter, it's probably better done in the VM.
However, most of the time you'll find you can reuse converters. I
most certainly would not expect the designer to code one, regardless
of whether or not we convert in the VM or in a VC.

--

Laurent Bugnion, GalaSoft [MVP]

unread,
Dec 1, 2008, 3:31:16 PM12/1/08
to wpf-di...@googlegroups.com

I want to chime in on that one.

 

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

Bill Kempf

unread,
Dec 1, 2008, 3:40:30 PM12/1/08
to wpf-di...@googlegroups.com
Interesting, but by that description I don't fall into either camp.
My goals are to 1) eliminate as much need for the code behind as
possible, so that designers don't ever write code, and 2) make unit
testing almost entirely possible with out any sort of UI automation.
However, I want to couple my VM as loosely as possible to the V. I
prefer converters in any scenario that has to do with conversions that
are coupled to the view.

--

Josh Smith

unread,
Dec 1, 2008, 3:55:30 PM12/1/08
to wpf-di...@googlegroups.com
Great feedback, Laurent.  Looking forward to your upcoming blog post about your experience with taking other approaches. ;)

I sense that I'm the odd man out in this discussion.  I'm very curious to know what concrete advantages others have gained by treating the VM as something clearly distinct and separate from the View.  What do you really gain from using value converters and code-behind logic, as opposed to putting that stuff into the VM?  I'm not opposed to that approach, it's just not how I've done MVVM so far.  While working on Crack.NET I created very dumb, passive Views and smart, demanding ViewModels.  I know that the good Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love to hear his thoughts on this.

josh

On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] <lau...@galasoft.ch> wrote:

Mike Brown

unread,
Dec 1, 2008, 4:03:30 PM12/1/08
to wpf-di...@googlegroups.com
I always said that I like my views to be like a stereotypical cheerleader: dumb and pretty. Note I said "stereotypical" I know that not all cheerleaders are dumb or even pretty for that matter. The same can be said for UI.

Mike Brown

unread,
Dec 1, 2008, 3:59:00 PM12/1/08
to wpf-di...@googlegroups.com
I think that in the series that Dan Crevier wrote, he definitely viewed the ViewModel as a "Model of the View". The domain model itself is where the logic of your application belongs. The ViewModel to me should indeed be just that.

On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] <lau...@galasoft.ch> wrote:

Josh Smith

unread,
Dec 1, 2008, 4:07:08 PM12/1/08
to wpf-di...@googlegroups.com
I agree with you on that, Mike.  Code-behind is where you handle events of controls in the View, and maybe update/call the VM in certain situations.  VM is where you store view state, handle user interactions, and indirectly manipulate the UI elements.  Model is for domain "stuff."  That's my way of seeing it, these days.

Josh

Bill Kempf

unread,
Dec 1, 2008, 4:09:20 PM12/1/08
to wpf-di...@googlegroups.com
Again, though, just because your view is dumb doesn't mean your view
model should be doing "presentation work" that tightly couples it.

--

Josh Smith

unread,
Dec 1, 2008, 4:11:44 PM12/1/08
to wpf-di...@googlegroups.com
If there is a one-to-one relationship between a ViewModel and a View, I don't see why tight-coupling is a concern.  If we're talking about "ModelViews" instead, as per my previous post, then I can see how the coupling issue becomes more important.  Do you agree?

Josh

Bill Kempf

unread,
Dec 1, 2008, 4:14:35 PM12/1/08
to wpf-di...@googlegroups.com
Not really. Even if I'm only ever going to have one view, that view
is likely to still be fluid in nature. What I mean by that is the
design of the view will go through many iterations throughout the
lifetime of the application, and tight coupling means changes to the
view also require changes to the view model.

corrado...@gmail.com

unread,
Dec 1, 2008, 4:32:49 PM12/1/08
to WPF Disciples
Josh,
From my point of view, converters become part of a common library i
can share among projects, at least most commons (e.g:
BooleanToVisibility for SL projects), of course I won't ask a designer
to write code, but normally i create a very dumb preview, then
designer kicks in and does the rest, this when designer is involved,
and believe me, not many customer have designers.
Let's say you have a IsAvailable property on VM that you want to use
both Visibility trigger and Enabled property, your approach is to add
an additional property of type Visibility and this "doubling" must be
done for every VM while i can avoid this using a converter.
About testing: why do i have to test "Visibility" issues? my VM should
tell me that an item IsAvailable then its the view responsability to
convert that info in visibility (today, tomorrow it might change, and
i don't want to modify my VM for the new UI needs)

-Corrado



On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote:
> 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-di...@googlegroups.com [mailto:
> > wpf-di...@googlegroups.com] *On Behalf Of *Marlon Grech
> > *Sent:* lunedì 1 dicembre 2008 20:16
> > *To:* wpf-di...@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???- Hide quoted text -
>
> - Show quoted text -

Josh Smith

unread,
Dec 1, 2008, 4:40:37 PM12/1/08
to wpf-di...@googlegroups.com
Thanks Corrado.  I get where you're coming from with this, but I'm still unsure of where the "boundary" is.  One could take this reasoning and push it to the extreme by stating "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?" 

Clearly, I know that nobody here is promoting that idea.  The balance of power, so to speak, between ViewModel and View is a spectrum in which I lean toward the left and many others seem to lean more toward the right.  I'm wondering what guiding principles one should use to find the sweet spot between the two opposing forces.

Josh

Jeremiah Morrill

unread,
Dec 1, 2008, 5:02:23 PM12/1/08
to wpf-di...@googlegroups.com
Josh,

Crack.NET has been one of my bases of learning MVVM.  I think the typed datatemplate resources feel very natural and lets the View be as only intelligent as it needs to be.  As you remember, this is where I was sorta getting pattern gun-shy in SL, given lack of built in support.  At this moment, I'm a proponent of the ViewModel-data/type-driven View which you mentioned here.  Before, in SL, I was initializing the VM in the codebehind and clearly it was more spaghettified if my goal was to fly the whole plane from the VM. 

As far as ValueConverters go, I would say I'm guilty of having my VM pander the View a little bit.  I would also add that I don't enjoy making VCs that much...but just like home-owners-associations, they are a necessary evil.  Most cases I would assume it's fine to have View friendly properties...but when you start getting over run by redundant properties (in other formats) is when I may consider a VC.

Just my 2cents as a newbie ;).  It does feel good to be able to follow these conversations now though...

-Jer

Corrado Cavalli

unread,
Dec 1, 2008, 5:08:34 PM12/1/08
to wpf-di...@googlegroups.com

I love this kind of discussions they helps spreading opinions and helps me (and hope others) play better  with this “quite young” but promising pattern.

I’m not absolutely saying your solution is bad, e.g. I use it when I need to enable an element as result of a complex condition (DataTrigger/Multibinding? No thanks! J) and, my point of view is that  patterns are ‘indications’ and I feel free to adapt them in the way the best fits my solution.

Unfortunately I keep seeing architects that apply patterns “as-is” even if that results in more complex code.

 

-Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: lunedì 1 dicembre 2008 22:41
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters

 

Thanks Corrado.  I get where you're coming from with this, but I'm still unsure of where the "boundary" is.  One could take this reasoning and push it to the extreme by stating "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?" 

Clearly, I know that nobody here is promoting that idea.  The balance of power, so to speak, between ViewModel and View is a spectrum in which I lean toward the left and many others seem to lean more toward the right.  I'm wondering what guiding principles one should use to find the sweet spot between the two opposing forces.

Josh

Josh Smith

unread,
Dec 1, 2008, 5:11:36 PM12/1/08