CslaDataProvider differences between WPF & Silverlight

CslaDataProvider differences between WPF & Silverlight

Old forum URL: forums.lhotka.net/forums/t/10245.aspx

MichaelMaddox posted on Thursday, April 07, 2011

I just spent many hours trying to figure out why data binding was working in a (CSLA) WPF app, but the same data binding failed (at runtime) in a (CSLA) Silverlight app.  There is a subtle difference that I couldn't find documented anywhere that I will document here for other people to hopefully find in the future.

The SilverlightSOA sample contains the following binding statement against a CslaDataProvider:

<Grid x:Name="LayoutRoot" DataContext="{Binding Source={StaticResource MyData}, Path=Data}" Background="Beige">

In WPF, this same binding statement would *not* include the ", Path=Data" portion of the statement.  So, when porting code in either direction, that is a critical change to make as there doesn't appear to be a way to do it that works across both that I could find (the ObjectInstance property is a close cousin of the Data property so I want to at least mention that property here).

This discussion is based on CSLA 4.1.

I'm sure there are other meaningful differences between the CslaDataProvider between WPF & Silverlight as the code base appears fairly different between the two, but the Path=Data seems to be one of the most critical.  One of the other significant differences is the syntax of the ObjectType property.

Here it is for WPF:

<UserControl ... xmlns:SilverlightSOA="clr-namespace:SilverlightSOA;assembly=SilverlightSOA" ...>

<csla:CslaDataProvider ... ObjectType="{x:Type SilverlightSOA:Person}" ... />

Here it is for Silverlight:

<csla:CslaDataProvider ... ObjectType="SilverlightSOA.Person, SilverlightSOA, Version=..., Culture=neutral, PublicKeyToken=null"  ... />

(The Version attribute is really set to "...", the other ..'s. I used were to make the code more brief.)

In general, it would be helpful to have at least one CSLA sample that exists for both WPF and Silverlight (and possibly Windows Phone as well if it's reasonable) that shows these subtle differences in an easy to diff code base to make porting code between platforms more cost effective.

I can tell a tremendous amount of effort has been made to share code between the platforms and make porting as trivial as possible and I appreciate that effort greatly.

This post is primarily intended to be informative, but it could also be used as a place to document other differences in the CslaDataProvider between WPF & Silverlight.

RockfordLhotka replied on Thursday, April 07, 2011

I strongly recommend against using the data provider model. Microsoft introduced this in WPF 3 (the first version of WPF). Since that time they've consistently moved away from the data provider model.

When we created CSLA .NET 3.x to support Silverlight, the data provider model still seemed like a valid approach, so we recreated it on SL. In retrospect, the fact that Microsoft didn't implement it in SL should have been an early clue that they didn't like the model anymore...

In any case, the only reason CslaDataProvider is still in the framework is for backward compatibility. Nearly everyone uses MVVM or MVP now. Even Expression Blend doesn't use data providers anymore.

Copyright (c) Marimer LLC