Multiple CslaDataProviders with IsAsynchronous = True

Devman posted on Wednesday, November 11, 2009

Hi,

Im not sure if im using the CslaDataProvider so here goes.... I have two CslaDataProviders on a form hooked up similarly to the ProjectEdit form from the project tracker sample as shown below. The main difference being both are set IsAsynchronous = True;

<csla:CslaDataProvider x:Key="ShelfLife" ObjectType="{x:Type Domain:ShelfLifeLookup}" FactoryMethod="Get" IsAsynchronous="True"/>

<csla:CslaDataProvider x:Key="Item"
                           ObjectType="{x:Type Domain:Item}"
                           FactoryMethod="GetById"
                           IsAsynchronous="True"
                           IsInitialLoadEnabled="False"
                           DataChanged="DataChanged"
                           ManageObjectLifetime="True"/>

I bind most of my controls on the form to the Item dataprovider, with no problems. However, when I bind a combobox to the ShelfLife DataProvider, no data is returned, no data portal fetch is called.

When i open another instance of the form with the same data, the ShelfLife DataProvider calls the data portal fetch and the combo is populated correctly.

I need both CslaDataProviders to fetch asynchronously due to an animation i use on the form during its creation/display.

Any pointers would be greatly appreciated as always :-)

Kevin Fairclough replied on Friday, November 13, 2009

Any ideas on this one, we're a bit stuck?

Does the CslaDataProvider support multiple async calls?

In ProjectTracker.ProjectEdit.xaml setting the two CslaDataProviders to IsAsynchronous="True" causes the form not to be displayed (even after a long wait...).

Regards
Kevin

sergeyb replied on Friday, November 13, 2009

I had to write a little helper class in these cases that I would pass the combo box provider in (or multiple for that matter), this helper would monitor data changed events, and raise its own event when all providers are done. In that final event handler I would call main provider. Otherwise, I was having binding problems…

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

From: Kevin Fairclough [mailto:cslanet@lhotka.net]
Sent: Friday, November 13, 2009 8:06 AM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] Multiple CslaDataProviders with IsAsynchronous = True

RockfordLhotka replied on Friday, November 13, 2009

I'm puzzled too.

I just created a very simple WPF app to try and replicate the issue in a focused setting, but the problem doesn't manifest.

I think the problem must have to do with some WPF data binding interaction. If you put breakpoints in the factory methods (or even back in CslaDataProvider itself) it turns out that the NVL object is never being requested by data binding.

In other words, CslaDataProvider isn't even being invoked by WPF to get the RoleList object.

The Project object, on the other hand, is retreived and returned to the UI. The DataChanged event is raised as appropriate, so WPF should be fully aware that the object is there...

RockfordLhotka replied on Friday, November 13, 2009

One more clue - it isn't dual async that's the issue. If you set the RoleList provider to not be async the problem still manifests.

In other words, the problem is purely around making the Project provider be async, and again, appears to be somehow related to data binding somehow being confused.

RockfordLhotka replied on Friday, November 13, 2009

Oh. Doh!

The problem in the ProjectEdit form isn't a bug. It is an implementation choice.

If you look at the XAML you'll notice that the Project provide has IsInitialLoadEnabled="False", and the actual load is triggered in the form's Loaded event handler in the code-behind.

That code in the Loaded event is not designed to support async behavior. It starts the provider's query, but immediately checks the Data property for a result - which it clearly can't do if the provider is async because the result won't have returned yet.

This probably just goes to show how evil code-behind really is, and why the MVVM pattern turns out to be better than the data provider model...

Or perhaps it illustrates that any code-behind you do write had better always be written assuming async, just in case some XAML jockey changes the data provider to be async :)