Help with first background thread in SL

I think I also want to refresh a bunch of calculated properties on the master record as I traverse and enter data on the child rows.

 

For example I have a counter of # of invalid records.  That changes with each modification of child data.  I really want the user to be able to zip through all the child records doing their data entry as fast as possible but when they stop and look up at the monitor they can see the latest status (or only wait a few milliseconds until its updated).

 

The ideal solution would be something where I kick off the master record refresh and if it isn't completed the next time it is called then I abandon and start over as the data is already stale.  I know I currently have too many linked pieces firing that is slowing it down so there can be a visual pause when tabbing from one field to another so I'm trying to streamline that but I think pushing all that processing onto another thread would be useful.

 

Thanks

 

 

I have a validation routine that I want to fire when triggering a rowChanged in a Master/Detail scenario.  I haven't done this before so I was looking for some advice before I wasted half a day I don't have playing around.

I'm also not entirely sure if I have to worry about the UI thread or not.  Basically I want to do this:

event RowChanging(){

     DoBackground -> CurrentMasterRowBO.ValidateChildData( )

}

The Validation of ChildData will call OnPropertyChanged for properties that are databound.  Does this mean that this can only run on the UI thread?

Is this a possible CSLA enhancement -> BO.RunBackGroundMethod("ValidateChildData")?

Thanks

jack

Thanks Rocky,

 

That sounds basically like the 'don't bother' I thought might come out of it.  A lot of the things I am doing are more validation rules so maybe once I've streamlined my process a bit more I'll see if plugging in some validation rules helps or not.

 

 

 

 

CSLA .NET 3.6 and higher does support async validation rules. Not business rules though, just validation rules.

You create an async rule method and add it to a property just like you do with a regular rule method. The difference is that the async rule methods are executed (potentially) on a background thread. All results are automatically marshalled back onto the UI thread for display to the user, and there's a property-level IsBusy concept so you can enable/disable a per-property busy animation in the UI (PropertyStatus does this automatically).

If you need a business rule (so the rule changes the state of the business object) then things are a lot harder, because CSLA .NET isn't threadsafe, and your business objects aren't threadsafe, and Silverlight's UI model isn't threadsafe.

In other words, writing a method that runs on a background thread that alters the state of a business object is extremely non-trivial. First you need to figure out a way to lock the business object so no other thread (including the UI) can interact with it. Second you need to figure out a way to block any events from being raised that might flow to the UI. Third, you need some way to accumulate a list of everything that did change, so you can marshall something back to the UI thread at the end of the process so the UI actually refreshes to show your changes.

None of this is easy to do - not necessarily even possible - which is why async rules are validation-only, and operate against a copy (snapshot) of the property values to be validated.