Is there a performance hit for a Silverlight application while implementing MVVM pattern using Databinding?

views:

341

answers:

+2 Q:

Is there a performance hit for a Silverlight application while implementing MVVM pattern using Databinding?

Hi,

I am implementing the Model-View-ViewModel (MVVM) pattern in one of the forms of my SL2 appication using INotifyPropertyChanged interface and TwoWay Databinding.

However I feel that due to this approach, my form behaves slightly sluggishly.

I just wanted to know whether using this approach is there any performance hit in such SL2 applications.

Thanks... Sudeep

+2 A:

I haven't noticed any slowdown. The Prism Reference Implementation, among many others, seems to be fast.

In fact, the binding system uses dependency properties. Just like the animation system. Part of the reason is that the values can be updated quickly by the framework.

Do you have any Value Converters in place?

Erik Mork 2009-06-16 15:20:37

+3 A:

I have not noticed any slowdown. We are doing a LOT of binding to INotifyPropertyChanged ViewModels and the UI seems to be extremely responsive.

Sure, there will be a hit for data binding vs direct data access... but that hit is so small that the benefit you get from data binding makes the small hit inconsequential.

Something to remember: The data binding is happening in the UI. There isn't a lot of high intensity processing happening at that layer. In addition, the UI renders on a separate thread. Those two things together make for an experience that feels very responsive, in my opinion.

Erik asked if you have any Value Converters in place? I would ask the same thing. If so, are they doing a lot of work? In my experience with MVVM, value converters are rarely needed anymore. Just some food for thought.

Brian Genisio 2009-06-16 15:27:04

Yes, in fact, I do have some Value Converters which are required to transform the values of the data structure to appropriate values on the UI depending upon slight biz logic. But imho, aren't Value Converters part of the "ViewModel" part of the MVVM pattern?

Sudeep 2009-06-17 03:35:56

@Sudeep: In most cases, ValueConverters are not even necessary with MVVM. For instance, before MVVM, you might bind a Visibility property to a boolean in your model object and use a Bool-Visibility converter. In MVVM, you just hang a Visibility propery off your ViewModel and get rid of the converter in your XAML. The only cases I have left for ValueConverters in MVVM are when the ValueConverter needs to convert to/from a View object, so I consider ValueConverters to be part of the View with MVVM.

Brian Genisio 2009-06-17 11:31:08

Hi Brian, thanks for your response. So as I gather from your response, are you suggesting that ValueConverters ideally make sense mostly when we have a TwoWay binding mode wherein the user's action has to be "Converted Back" into appropriate data value within the Model?

Sudeep 2009-06-17 16:30:50

No, I am more suggesting that ValueConverters make sense when the output of the ValueConverter is a View object. Brushes (for example) are part of the view, so haveing a Brush property on your ViewModel is mixing metaphors (and hard to test). Instead, a ValueConverter makes sense here, and would live in the View. In the case of Two-Way binding, that still gets handled in the ViewModel for most cases.

Brian Genisio 2009-06-17 19:00:37

How about say a control's target property like Visibility (that I wish to set according to some boolean condition in my model)? In such a case, is it a good practice to expose a property in my ViewModel of return type as "Visibility" or should I have a ValueConverter to convert from a boolean property to a Visibility value? (Same question of mine can be extended to say SolidColorBrush value that I want to assign to the ForeColor target property of a control.) e.g.public Visibility IsVisible{ get { return (m_someCondition) ? Visibility.Visible : Visibility.Collapsed; }ORuse ValueConverter

Sudeep 2009-06-18 18:46:13

That is a REALLY good question. Window.Visibility is technically a view-level enumeration. Since I really only target my ViewModels towards WPF and Silverlight, I tend to put a Visibility typed property in my ViewModel, but some may question the purity of that. SolidColorBrush, on the other hand, will need a converter, unfortunately... Since SolidColorBrush derives from DependencyObject, it clearly needs to live in the View layer, which means you need to convert that one. That is why I say you can do away with ValueConverters "In most cases"

Brian Genisio 2009-06-20 16:43:35

Thanks Brian for your reply...

Sudeep 2009-06-22 09:19:30

+1 A:

We do a lot of MVVM with Prism and haven't noticed a performance hit. Quite the opposite - the app often demos faster than it's low-tech Windows counterpart.

James Cadd 2009-06-16 16:00:27

Check as well in which places you need two way binding in which other just one time binding.

Braulio 2009-06-17 08:48:49

ansaurus

tags:

views:

answers:

Is there a performance hit for a Silverlight application while implementing MVVM pattern using Databinding?

related questions