Thought: MVVM eliminates 99% of the need for ValueConverters

13,623 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
to wpf-di...@googlegroups.com
Me too, Corrado.  Having discussions like this really help open new horizons for me.


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

I'd take complex code over complex XAML any day!  As you pointed out, hanging a property off the VM which returns a complex calculated value is definitely easier to maintain than a fat chunk of XAML using MultiBindings and a MultiConverter. 

Josh

Josh Smith

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

I'm glad Crack has had the fringe benefit of being educational!  That's great news for me!! :)

Josh

Jeremiah Morrill

unread,
Dec 1, 2008, 5:15:55 PM12/1/08
to wpf-di...@googlegroups.com
Don't want to inflate your ego dude, but if code was porn, the Crack.NET source would be illegal in all 50 states!  Too hot!

Many thanks though.

-Jer

Laurent Bugnion, GalaSoft [MVP]

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

You know, thinking about what I wrote earlier, I think that the “sweet balance” really depends on a lot of factors.

 

- Does your project have designers or not?

- How experienced is your team?

- How much unit testing do you do (don’t laugh, I love unit tests but many managers hate it and don’t see the value of it, true story)

- What is your model made of and where does it come from?

- and of course personal preferences.

Jeremiah Morrill

unread,
Dec 1, 2008, 5:13:05 PM12/1/08
to wpf-di...@googlegroups.com
One question, about creating a life cycle for a VM, is what mechanism would you use in SL to do this?  I was hoping not to have to do anything with the VM in the code-behind as this would create too much coupling (for my liking).

Josh Smith

unread,
Dec 1, 2008, 5:28:55 PM12/1/08
to wpf-di...@googlegroups.com
Thanks Jer.  Glad you like it.  :)

Josh Smith

unread,
Dec 1, 2008, 5:30:07 PM12/1/08
to wpf-di...@googlegroups.com
You're totally right, Laurent.  It's a moving target.  Regarding the "managers who don't like unit testing" thing...been there, done that. :-\

Josh

Josh Smith

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

In Crack.NET there is only the "Initialize" phase of the lifecycle.  This occurs in InjectedWindowViewModel, as seen below...

TWorkspace FindOrCreateWorkspace<TWorkspace>() where TWorkspace : WorkspaceViewModel, new()
{
    TWorkspace workspace = this.Workspaces.FirstOrDefault(ws => ws is TWorkspace) as TWorkspace;

    if (workspace == null || workspace.AllowMultipleInstances)
    {
        workspace = new TWorkspace();
        workspace.Initialize(this);
        workspace.RequestClose += this.OnWorkspaceRequestClose;
    }

    return workspace;
}

ScriptoriumViewModel overrides Initialize to perform some setup code.  The base impl only sets the _owner field.

If I ever need to have a "Dispose" phase for ViewModel objects, I'd put it into InjectedWindowViewModel like so...

void OnWorkspaceRequestClose(object sender, EventArgs e)
{
    WorkspaceViewModel workspace = sender as WorkspaceViewModel;
    workspace.RequestClose -= this.OnWorkspaceRequestClose;
    _workspacesInternal.Remove(workspace);

    // This method call does not exist...
    workspace.Dispose();

}

Josh

Jeremiah Morrill

unread,
Dec 1, 2008, 5:48:46 PM12/1/08
to wpf-di...@googlegroups.com
Ah ha!  I was under the impression that you guys were talking about running an initialize on the View's loaded event...which I haven't had a need for thus far.  I know as this project gets bigger, I may need, or decided I need some sort of life-cycle in the VM..so I'm trying to sneak in as many questions now as possible :)

-Jer

Josh Smith

unread,
Dec 1, 2008, 5:51:52 PM12/1/08
to wpf-di...@googlegroups.com
I wasn't referring specifically to the implementation details of how a lifecycle is managed.  If people are loading VMs from the View, then it makes sense to manage the lifecycle from the View.  In my apps, I load the View in response to putting a VM into the UI, so I manage the lifecycle from the place in my app that creates/loads/removes VM objects.

josh

Laurent Bugnion, GalaSoft [MVP]

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

Jer, using the Silverlight toolkit you can now define implicit styles so I *suppose* (but I didn’t try it) that you could also use the ImplicitStyleManager to define a View for a given view model type… interesting thought, I have to try that… tomorrow. ;)

 

http://blog.galasoft.ch/archive/2008/10/28/new-silverlight-controls-suite-delivered-by-microsoft-pdc08.aspx

 

Laurent

Jeremiah Morrill

unread,
Dec 1, 2008, 6:04:13 PM12/1/08
to wpf-di...@googlegroups.com
I'll have to check it out...Actually, I'm going to check it out right after this email!

I've been using the ResourceSelector from the SL Extensions, which is a simple, but very powerful class.  Totally makes up for the fact there are no typed datatemplates.

So essentially, I have a VM with a property called CurrentViewModel, of my ViewModelBase type.  I just have content control bind it's content to this property, and bind the ContentTemplate to a DataTemplate that uses the ResourceSelector.  This way, whatever .NET type my VM is, the View will pick the right datatemplate...just like WPF.  Here is the XAML for it.  The "x:Key="LoginViewModel", LoginViewModel is the name of my ViewModel type.  It also supports the type FullName if you really need.

    <UserControl.Resources>
        <Data:ResourceSelector x:Key="controlTemplateSelector">
            <ResourceDictionary>
                <DataTemplate x:Key="LoginViewModel">
                    <Views:LoginView Height="{TemplateBinding Height}" />
                </DataTemplate>
                <DataTemplate x:Key="EventQueryViewModel">
                    <Views:EventQueryView />
                </DataTemplate>
            </ResourceDictionary>
        </Data:ResourceSelector>
        <DataTemplate x:Key="controlItemTemplate">
            <ContentControl Content="{Binding}"
                            ContentTemplate="{Binding Converter={StaticResource controlTemplateSelector}}" />
        </DataTemplate>
    </UserControl.Resources>
    <Grid x:Name="LayoutRoot">
        <Image Source="Assets/mainBackground.jpg"
               Stretch="Fill"
               Opacity="0.5" />
        <Controls:SwappableContentControl Content="{Binding CurrentViewModel}"
                                          Background="Transparent"
                                          ContentTemplate="{StaticResource controlItemTemplate}"
                                          VerticalAlignment="Center" />
       
    </Grid>
</UserControl>

Jeremiah Morrill

unread,
Dec 1, 2008, 6:28:26 PM12/1/08
to wpf-di...@googlegroups.com
This ImplicitStyleManager is rad Laurent!  It doesn't solve the issue of no typed datatemplates, but it sure fixes other issues..Like no support for merged resource dictionaries...of of course, implicit styles =P

-Jer

Mike Brown

unread,
Dec 1, 2008, 6:35:14 PM12/1/08
to wpf-di...@googlegroups.com
Prism does a good job at handling all that wiring cruft that you don't want to deal with and I hear that the new version targets SL so that the same VM CAN be used for an SL app as well as a full WPF app. BTW, now that SL will have 3D and hardware acceleration capabilities, is there anything preventing it from being the preferred desktop client framework?

Jeremiah Morrill

unread,
Dec 1, 2008, 6:40:42 PM12/1/08
to wpf-di...@googlegroups.com
>>is there anything preventing it from being the preferred desktop client framework

Hard to say until we see what the caveats are to 3D and HW acceleration.  Flash 10 has those, but it's still neutered and sandboxed.

The apps I usually work on (if they were WPF), are pretty market specific...So I *need* full trust, COM interop, p/invoke, etc.  Most biz apps don't need this, but I don't think SL will take down WPF anytime with me ;)

-Jer

Dr. WPF

unread,
Dec 1, 2008, 7:37:57 PM12/1/08
to wpf-di...@googlegroups.com

This is a GREAT discussion!  Sorry I’m so late to it and apologies in advance for the lengthy reply... too much fodder!

I agree with many things already stated.  Josh originally proposed the purpose of the VM as follows:

[It] takes "raw" data and converts it into something presentation-friendly, and vice-versa.

That is a good description of the purpose of the VM, but the question then becomes just how far should the VM go to make the data “presentation-friendly”?  Should it, for instance, have specific knowledge of the presentation technology?  Generally, I try to avoid creating a VM that has a dependency on a specific V technology.  Rather, I tend to agree with Paul’s comment here:

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.

Incredibly well stated.  That is exactly how I think of the VM.

I agree with most of Bill’s comments too.  Ideally, changes to the view should not require significant changes to the VM.  Value converters are great for maintaining a loose coupling between VM and V.

Josh also said:

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.

I agree.  This is where the VM gets muddy.  The muddiness comes from the differences between what Josh describes as ViewModel and ModelView classes.  Most of my VM classes can be broken up along these same two categories.  I have some VM classes that exist solely to support the view and some VM classes that exist to support the model.  The classes that support the model obviously belong in the VM (even though a better term would be MV).  But just about every user control, window, page, (sometimes  even tabitem), etc, I create will also have a VM class that provides state for that control. 

The cleanest approach might be to clearly separate these within folders called VM and MV, but so far I’m way too lazy for that.  Instead, I tend to explain this muddiness away as part of the “poo”.  ;-)

I probably differ with Josh a little on how the UI-specific VM classes are used by the view.  Typically, if I have a VM class that supports a user control, for example, the VM class will still only provide a “conceptual” state for the control (and may thus require value converters).  The control, itself, will then expose the necessary DPs to change state (hide and show the dialog, trigger template changes, etc) and those DPs will be bound directly to properties in the VM class.  This allows the VM to still drive the application conceptually, but view-specific code stays contained within the view class.

One of the coolest suggestions in this thread was by Paul:

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.

Dude, that is begging for a CodeProject article!  :-D

Mike noted a suspicion that DPs are enabled via a custom type descriptor provider.  There is definitely a link here, but maybe not the one suspected.  The binding engine actually doesn’t rely on the provider to establish the binding at all.  (It is much more optimized when binding to a DO...  It knows that the DO has a property bag and it uses the supplied property path to look up the property.)  However, the framework does expose a custom DependencyObjectProvider (which is a TypeDescriptionProvider) to surface DPs to designers like Cider and Blend.  More importantly, if you were to expose a custom provider on a non-DO, then it would be used by the binding engine to look up properties (since those bindings are resolved via type descriptor/reflection).

Moving on...  Josh noted:

While working on Crack.NET I created very dumb, passive Views and smart, demanding ViewModels.

. . .

I'm glad Crack has had the fringe benefit of being educational!  That's great news for me!! :)

Cheers, dude!  Well done.  :-)

I think the MVVM implementation in Crack.NET is very clean and exemplary.  I especially like the template-instantiated view approach there.  Using this approach, you can create and manipulate VM objects, regardless of whether there is a view associated with those objects.  For me (as a developer), writing an application is more about writing the VM anyway.  (Whereas, for our designers, writing an application is more about creating the views.)

And finally, I think Laurent nails it when he says the balance depends on the scenario and resources at hand... including personal preferences.  My preferences seem to change slightly with each new project.   Bottom line...  It’s great to have this dialog so we can all benefit from each other’s experience.

Dr. WPF - Online Office at http://www.drwpf.com/blog/


Josh Smith

unread,
Dec 1, 2008, 7:48:56 PM12/1/08
to wpf-di...@googlegroups.com
Fantastic summary and insights, Doc!  Well done, sir.

It seems most people agree on this "ViewModel as a purely conceptual state of the View" idea.  I agree somewhat, but will need to see cold, hard evidence of this in practice as being better before I'll wholeheartedly agree.  Can you point out a specific place in Crack.NET where you think I might have put too much View-specific logic in the VM?

Josh

Josh Smith

unread,
Dec 1, 2008, 10:15:32 PM12/1/08
to wpf-di...@googlegroups.com
>> For me (as a developer), writing an application is more about writing the VM anyway.

That sentence really resonated with me, Doc.  I feel exactly the same way.  Once you break a client app into the M-V-VM pieces, the M and VM definitely become the most "interesting" pieces to work on, for the most part.  It can fun to write the occasional bit of View-specific code that does something really interesting with the element tree, etc, but for the most part Views are better left to designers and tools that generate XAML.

On Mon, Dec 1, 2008 at 7:37 PM, Dr. WPF <a...@drwpf.com> wrote:

Zhou Yong

unread,
Dec 2, 2008, 12:04:16 AM12/2/08
to wpf-di...@googlegroups.com
For view specific code, I prefer to wrap them into attached behaviors.

Yong
--
Zhou Yong
Approaching the world in the WPF way
http://shevaspace.spaces.live.com/

Dr. WPF

unread,
Dec 2, 2008, 1:31:59 AM12/2/08
to wpf-di...@googlegroups.com
> Can you point out a specific place in Crack.NET where you think I
> might have put too much View-specific logic in the VM?
>
> Josh

No, not at all in your VM code.  I haven't even noticed any place where you leveraged the VM to perform value conversion in Crack.NET.  Your code seems very pure and view-agnostic to me.

Now as for my code... there is definitely view-specific logic in the VM code that I added!  It made my brain hurt trying to devise a VM approach for the Snoop-like element tree explorer.  In fact, I went through several rounds of inner turmoil before I reconciled that it was indeed appropriate to have Visual references in the VM.  (It certainly felt wrong though.) 

This is where Crack.NET differs from most apps.  It is a debugging tool.  And the specific part I was working on was aimed at debugging the "view" of a WPF application.  So the fact that I had routines within the VM to walk the visual tree was actually quite appropriate.  The key thing to note is that I was *not* walking elements of Crack.NET's view... rather, I was walking elements of the debuggee's view.  Those were the very elements represented within the view model. 

(In fact, there was even a property on a VM class of type VisualBrush.  Boy did that feel wrong!  Brush and Visual are examples of presentation classes that I would *never* expect to see referenced in the VM.  But again, it's appropriate when you recognize that these are actually VM objects in Crack.NET.  Weird, but appropriate.)

Crack.NET also gets a big pass from me on how strict I would be in keeping the V and VM separate.  It is a special purpose tool whose UI will most likely only ever be presented using WPF (again, since its a full-trust, Windows-specific debugging tool).  That makes poo more forgivable, imho, although I haven't observed any yet.  ;-)

So Crack.NET is a great "implementation" example of MVVM, but it is not necessarily analogous to more typical data visualization apps where you might want to support both a WPF and SL view.


Laurent Bugnion, GalaSoft [MVP]

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

Whew I am so relieved to wake up and find only 13 new posts in that thread, instead of the 242 I was dreading.

 

Josh, you say you love working on the M and VM ;) I love that too but I have to say I really like working on the View too and especially XAML. Yes you heard that right, I love XAML ;) Man this is such a change from WinForms, where I just *hated* the part where I had to re-layout all the controls when the window’s size was changing just a tiny bit… I love the way that XAML and the flow layout are taking care of that for me. There is such an amazing elegance in that. I guess that puts me a little more between the developer and the designer, which is exactly what we, at IdentityMine, call an interactive developer (or integrator). (notice how I say “we” after just a day? ;))

 

Fantastic thread.

Marlon Grech

unread,
Dec 2, 2008, 4:41:00 AM12/2/08
to wpf-di...@googlegroups.com
Sorry for being late....

RE: Should Designers write up your ValueConverters?
HELL NO! Designers are evil creatures that eat a lot of apples and that cannot touch our beloved Visual Studio.

What I love about a ViewModel is that by looking at the properties you can see what it is really doing and you do not worry about how the View looks. This means that I prefer creating a Boolean property to show a state of true/false instead of Exposing a Visibility property just because that is what the View needs. If a dev looks at a bool property he will understand more what is really happening.
Besides this we devs don't really know what designers want. Do we? Maybe Designers decide that according to the value False they will lower Opacity instead of making a control invisible. And that is where a library of ValueConverters come in handy. You can have a BoolToVisibilityConverter and a BoolToOpacity converter ( or when possible leave the converters home and use a Trigger :) ) (Yes I said Library because 80% of the Value converter are all the same)

The way I see it that, the ViewModel cannot expose properties that are too UI related such as Visibility for example, if you do so, you are altering the Designers "creativity" because you as a Dev are altering what the designer is thinking. Sometimes I see the VM-V as lookless controls... The control exposes properties and the ControlTemplate decides how to make the control look like.



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



Paul Stovell

unread,
Dec 2, 2008, 4:59:10 AM12/2/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.

A lot of this is to do with process. Starting from wireframes, a common interaction design tool is to create a "device catalog" and pre-build some of the common controls, converters and behaviors. For example, if UI design dictates that you'll have 12 forms with human Name text boxes, and you want to auto-capitalize people's first names, then you'd design and build those little "parts" of the application at that time. I've found there's usually a high degree of reusability with these converters, and the number of them never actually gets so high (though YMMV).

Then you can take each wireframe and turn them into a design spec, and decide the responsibilities of the view, model and so on. If you don't, you create work items, and design the V and the VM together. Chances are if you hadn't built a Value Converter yet, you probably also wouldn't have built the property on the ViewModel either. So you might avoid "asking the developer to write a bunch of one-off converters", but you'll just end up "asking the developers to write a bunch of one-off properties" :-) And designers should have better things to go on with while they wait.

Paul


On Tue, Dec 2, 2008 at 6:32 AM, Josh Smith <flappl...@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 <corrado...@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

On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappl...@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???

 





--
Paul Stovell
http://www.paulstovell.net

Mike Brown

unread,
Dec 2, 2008, 6:49:35 AM12/2/08
to wpf-di...@googlegroups.com
I believe that good tooling can address some of this. Naming conventions can help as well. Then again there's basic design for your use cases/stories/scenarios. I'm starting an article series and talking about a lot of this stuff in there. I hope to have the first part of the series ready today. I believe that code craftsmenship is better targeted at creating this tooling that will generate standardized code than implementing this code manually. I'm not arguing that the code should be the final product. However, having code that takes a design and generates code from templates brings us that much closer to the holy grail of reusable code.

Josh Smith

unread,
Dec 2, 2008, 8:39:09 AM12/2/08
to wpf-di...@googlegroups.com
>> However, having code that takes a design and generates code from templates brings us that much closer to the holy grail of reusable code.

Off topic, but reusable code is not the holy grail.  It is just a means to an end.  The holy grail is decreased cost for development and maintenance of an application.  Reusing code is just one possible way to achieve that. 

Josh

Josh Smith

unread,
Dec 2, 2008, 8:41:50 AM12/2/08
to wpf-di...@googlegroups.com
Doc,

I agree that the VM for Element Tree Explorer is a strange bird, in the sense that another app's View is its Model.  I hope to carry the torch forward during my vacation time at the end of this month.

Josh

Josh Smith

unread,
Dec 2, 2008, 8:48:15 AM12/2/08
to wpf-di...@googlegroups.com
>> The way I see it that, the ViewModel cannot expose properties that are too UI related such as Visibility for example, if you do so, you are altering the Designers "creativity" because you as a Dev are altering what the designer is thinking.

That's an interesting point.  I must disagree, though.  The View-specific properties are put on the ViewModel because the designers request it, not because the developer decides it should exist.  I've worked in the designer/developer workflow several times, and I usually find myself in a situation where the designer needs some property to bind against that isn't "there" already.  That's when I add a View-specific property to the VM.

Josh

Marlon Grech

unread,
Dec 2, 2008, 8:58:06 AM12/2/08
to wpf-di...@googlegroups.com
Josh I guess it works both ways... Sometimes it is the case where Designers want something and you would update the view model. Can't argue with that !

cool... this thread is cool!!!


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



Josh Smith

unread,
Dec 2, 2008, 9:03:20 AM12/2/08
to wpf-di...@googlegroups.com
Good points, Paul.  You're right about how this all boils down to process.  And yeah, my point about "one-off converters" is moot, when you put it that way.  :)

Josh

Bill Kempf

unread,
Dec 2, 2008, 9:26:03 AM12/2/08
to wpf-di...@googlegroups.com
> The way I see it that, the ViewModel cannot expose properties that are too
> UI related such as Visibility for example, if you do so, you are altering
> the Designers "creativity" because you as a Dev are altering what the
> designer is thinking. Sometimes I see the VM-V as lookless controls... The
> control exposes properties and the ControlTemplate decides how to make the
> control look like.

This is great insight, because lookless controls DO follow the M-V-VM
pattern (you know, I hate that we've all grown so comfortable using
this pattern name, when it's really MVP that's been around so long...
that's why you'll often hear me call it MVPoo and other such
references, because the good Doc hit this one on the head). That's
exactly the point of view you should take when considering what goes
into a VM. Yes, it can get murky from time to time, because our views
are generally MUCH more complex than a simple control, but the purity
is still what you should strive for here. Of course, don't give up
being a pragmatist. Be willing to ignore "best practices" when they
stand in the way of getting the work done. ;)

Mike Brown

unread,
Dec 2, 2008, 10:15:45 AM12/2/08
to wpf-di...@googlegroups.com
Sorry for not expressing my sarcasm clearly enough. But yes I agree that reusable code is not the goal by itself. But rather the decreased cost and what not. Essentially, what I'm saying is that experienced developers cost a bit more than entry-level developers. One way to decrease the development/maintenance costs is to use your experienced developers as toolsmiths. This is doubly beneficial because you're able to leverage the experienced developers' experience to make your "greener" developers more productive while still maintaining standards.
 
I liked where "Acropolis" was going and was somewhat surprised that we didn't hear more about it at PDC. Paul and I both spoke about the concept of a "Domain Tree". I think that having a declarative framework for your Domain Model/View Model would be the first step to enabling something like an "Oslo"-based designer for wiring up your application with the Domain, View Model, and even a wireframe view generated from the model.

pete.o...@gmail.com

unread,
Dec 3, 2008, 3:46:04 PM12/3/08
to WPF Disciples
All, sorry for dragging this discussion on but it's fascinating and I
have a slightly different viewpoint on the whole ViewModel issue. One
of the things I love about WPF is the way you can freshen up an
application simply by supplying new styles and a slightly updated
view. As a business owner, it's slightly sneaky, but you can satisfy
the needs of a client for change just by changing the look slightly.
MVVM, as a pattern, is a great mechanism for providing this capability.

Laurent Bugnion, GalaSoft [MVP]

unread,
Dec 3, 2008, 3:57:00 PM12/3/08
to wpf-di...@googlegroups.com
Hey Pete,

That's one of the main reasons why we used MVVM at Siemens (I used to work
there before I changed to IdentityMine from the 1st of Dec), because we
wanted to be able to give different look&feel to our framework application
depending on the market in which we are going to sell it. For example, the
American product will look slightly different from the European or Asian
version.

Can you elaborate on what you mean with "sneaky"? I think I understand what
you mean but would like to be sure.

Cheers,
Laurent

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of pete.o...@gmail.com
Sent: Wednesday, December 03, 2008 9:46 PM
To: WPF Disciples
Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for
ValueConverters

Peter O'Hanlon

unread,
Dec 3, 2008, 4:01:24 PM12/3/08
to wpf-di...@googlegroups.com
Laurent - by sneaky, I mean that you get to satisfy a clients need for changes without adversely affecting the underlying code. As far as they are concerned, they've got an updated application. As far as you are concerned, the internal logic has been protected and the application has been spruced up.
--
Peter O'Hanlon

Laurent Bugnion, GalaSoft [MVP]

unread,
Dec 3, 2008, 4:29:23 PM12/3/08
to wpf-di...@googlegroups.com

It’s what I thought. I kind of agree. For us, this was not sneaky, this was an added value, in the sense that modifying the look and feel of the app without touching the engine was considered as a requirement by our marketing, for example for branding, or as I mentioned already for localization. But then again, my client was the marketing department at Siemens, so we were all in the same boat ;)

Reply all
Reply to author
Forward
0 new messages