IValueConverter vs Setting property in ViewModel

IValueConverter vs Setting property in ViewModel

I am refactoring existing code and run into very bad pattern - one of the ViewModel's property  contols Visibility of XAML control (via binding).

of cource it is not right MVVM pattern - visibility must be calculated by IValueConverter....

Guy who originally wrote this code supposed to be "professional" and i am trying to understand why he did this..
Is it related to performance?

P.S.
I know that telerik doesn't recomend to be too crazy abt converters because of performance issues...

 

Answers & Comments...

Answer: 1

I don't think anything is hard and fast in MVVM so having Visibility property isn't HORRIBLE, but I wouldn't do it that way.  I know of no real reason to do it that way.  I prefer a boolean variable in the Viewmodel that indicates state and then use the ValueConverter to change that to a Visibility.  I think it makes the Viewmodel more visible and allows it to be used WITHOUT a UI.

Answer: 2

Using a converter will hurt performance.  Depending on how much you're using the converter or how cpu intensive the conversion process is, the users may or may not notice the difference.  We may be talking about milliseconds which is fine, until you're executing the converter 1000 times.

What you have to do, as a developer, is judge the performance you gain versus the portability you lose by making your ViewModel platform -specific.

If you want the best of both worlds, and aren't afraid of a little extra work, you could make a platform-agnostic version of you ViewModel that uses booleans and inherit from it in a Silverlight-specific version that allows for direct use of the Visibility enum.

Answer: 3

I haven't done any tests, but I would be surprised if a 1000 invocations of a value converter would be very long.  What WOULD be long would be if you made 1000 CONTROLS which used a value converter.

I think normally a UI will have so few controls that a converter couldn't make any significant difference.  And if there ARE 1000 controls, they would probably best be put inside some sort of VirtualizingStackPanel container or other virtualizing control so that only a few require actual rendering and would then require calling the valueconverter.

But, I'm just guessing.  I've never seen performance be an issue on the SL client.

Answer: 4

Forget about performance it is not relevant.  Whether you do it in the ViewModel or you do it in the value converter at some point you are doing the translation from a Boolean result to a Visibility value.

I would suggest that the ViewModel should expose a Boolean value.  The Converter from Boolean to Visibility is trivially simple.

It's really not worth stressing about.  Do something and move on.

I would guess that the original programmer exposed a Visibility in the ViewModel because it is so trivial and unimportant that it is not worth bothering with, write some code that works and move on to the important things is what I suspect was the thought process.  (Seriously, what percenage of all the ViewModels ever written have been used in both a Silverlight application and a non-xaml application?)

Answer: 5

Given a choice of writing a Visibility property or a Boolean property, I'd recommend the Boolean.  OP I think is looking for guidance.  Everything else being equal, just have the Viewmodel maintain STATE.  Then let the UI interpret that state if necessary.  I think that should be the general guideline.

You can, of course, code anything anyway.  It might only be an issue IF you want to share the code, but if you've done Boolean, you will be good to go.  If you've done Visibility, it might not be.

But doing a Visibility property isn't a HORRIBLE thing.  Just not recommended, I would say.

I'm guessing the originaly programmer modeled his code after someone else's that used Visibility.  I've seen examples on the web, and I've DONE that to, but once I found out about the ValueConverters, I think it makes more sense to just have Viewmodel maintain state.  And usually it will result in more readable code.

Answer: 6

Hey guys.

Looking at another part of the code I suspect that previous guy just started with silverlight - i feel he was asp developer and applied his experience in silverlight. Most likely he didn't know abt converters at that time -)))).

Btw, people raised interesting point - if app has 1000 controls it will be way slover than call converter 1000 times....
Also sometimes virtulization is not good at all. For situation if you have very complex GUI, with many controls and templates virtualization may slow down scrolling so much that you don't want it... My point that you can see it only from real appication.

Cheers

---