Silverlight CslaDataProvider Data vs. ObjectInstance property

Silverlight CslaDataProvider Data vs. ObjectInstance property

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


SonOfPirate posted on Sunday, August 16, 2009

Forgive my ignorance, but I am confused why we have two properties on the CslaDataProvider class for accessing the business object.

I'm not a big WPF user, but I understand that in WPF the DataSourceProvider class provides a read-only Data property which is supposed to return the "underlying data object" and the ObjectDataProvider presents an ObjectInstance property which has the following logic:

  1. If the ObjectType property is defined by the user, an instance of this type will be created and returned by the ObjectInstance property
  2. If an object is explicitly set to the ObjectInstance property:
    1. If that object is a DataSourceProvider, the object's Data property will be returned
    2. Otherwise, the object will be returned

It seems to be a pretty convoluted way to allow users to set the data object.  Was the intent to provide a base property that would always allow access to the data object but provide a more useful way in the subclasses?  I notice that the XmlDataProvider exposes a Document property which is essentially a strongly-typed version of ObjectInstance.

Anyway, in looking at the CslaDataProvider for Silverlight, I see that both properties are still present even though there is no framework (base class).  Can I ask why we need both properties?

If I bind my UI to ObjectInstance, I don't get any of the internal workings that are triggered when polling the Data property.  But, to define the data object, I must use the ObjectInstance property.  This seems kinda inconsistent to me.

Can anyone help me wrap my head around this?

 

RockfordLhotka replied on Monday, August 24, 2009

You'll really have to ask Microsoft. I modeled CslaDataProvider off ObjectDataProvider, and it has a Data property for data binding (that's part of the data provider infrastructure in WPF) and an ObjectInstance property to allow code to get/set the object value.

When we created the SL version of the component, as with all of the code, my goal was to maintain as much parity between .NET and SL as possible, so the same implementation came across.

As I mentioned in a post earlier today, I rather suspect that the whole data provider infrastructure is on its way out. While it was introduced at the beginning of WPF's lifetime, it is clear that it isn't trendy and a lot of people seem to dislike it...

Copyright (c) Marimer LLC