CSLA for Silverlight - Updating child objects

nobby_trussin posted on Thursday, October 01, 2009

Hi,

I am developing an 'Edge' application as described in Rocky's CSLA for Silverlight videos whereby my data is retrieved in the local portal (on the Silverlight client).

However, due to the asynchronous nature of Silverlight, I am a bit confused as to how child objects are updated when a list is saved.

I have a class defined as follows:

public class DDList : BusinessListBase

I want to be able to call BeginSave() on an instance of the list and have it iterate all its child objects to save each of them.

In CSLA for Windows, the list could just iterate its children one by one and save them individually. How is this done in CSLA for Silverlight? Is there a CSLA pattern for doing this or do I need to manually keep track of which event handlers have fired on the child objects and when all have completed, then fire the completed event on the list?

I hope I explained that so it made some kind of sense :)

Thanks for your help

Dan

RockfordLhotka replied on Thursday, October 01, 2009

I would hope that the service you are calling accepts all your data in one message - the parent and child data all together. Otherwise the service design seems really flawed - it would perform terribly and could never guarantee any data integrity.

Assuming that's true, then what your client code needs to do is assemble all the data (parent and child) into a single XML document or message object (DTO graph) that you can pass to the service.

The easiest way to do that is to have the DataPortal_Update() method create the root node of the DTO graph, and pass that as a parameter to the child update method.

That way the DTO graph comes into each Child_Insert() and Child_Update() method, and the child object can add its own data to the DTO graph (or XML message).

Once all the objects have had the opportunity to put their data into the DTO graph, the DataPortal_Update() can make one async call to the service to send the data over the wire.

nobby_trussin replied on Friday, October 02, 2009

Hi,

Thank you kindly for your reply. Well that's how I started writing the app - passing all the data in one DTO. However, I reached a stumbling block and decided I was doing it wrong - doh!

The scenario was as follows:

I have a BusinessBase object called Customer which has a child BusinessListBase called DDInfoList which contains DDInfo BusinessBase objects.

Lets say I fetched an existing customer from the database and then added 1 new DDInfo item to the DDInfoList and edited one existing DDinfo item. When I assemble a customer DTO, populated with all its child objects, and pass it to the dataservice for persisting, how does the service know which records in the child list to update and which to insert as it has none of the CSLA IsNew functionality?

I did consider passing an IsNew flag to the service but then thought that by doing this I was just recreating what CSLA already did and that I was, therefore, going about solving the problem all wrong.

Thanks again for your help.

Regards

Dan

RockfordLhotka replied on Friday, October 02, 2009

You are encountering some of the issues that make SOA so darn expensive.
I've said for years that the S in SOA is a $, and I wasn't kidding.

Defining a good service interface is very important, and if the service
allows for batch updates of data (which is what we're talking about here),
then the contract needs to somehow incorporate insert/update/delete
semantics - or the service must be able to infer which operation to perform
(presumably through mystic chants or something?).

If you are creating a Silverlight edge app, the architectural model you are
using is one where there are (at least) TWO SEPARATE APPS.

As you work on the service app, you must NOT THINK ABOUT THE SL CLIENT. You
must think about ANY client - the multitude of clients that you'll have over
time using your service interface. You need to design the service and the
service interface with no specific assumptions about any one client.
Instead, remember that you are building an app that just happens to have an
XML interface (instead of HTML or whatever). You can't trust any input, and
your interface must include enough detail and information so your service
can do its job. Which often means including insert/update/delete metadata in
the contract.

As you work on the client app, you should treat the service much like a set
of stored procedures. Ones that are out of your control, and that are
maintained by an evil DBA in the basement. Down by the furnace, where you
dare not go for fear of being burned. Remember, the service can't change its
contract on the whim of any one client, because that'd break all other
clients. If the client needs to do more work to overcome a limitation of the
service, so be it - that's cheaper than breaking all other clients using the
service.

Yeah, SOA is pretty complex, and is not cheap. But presumably it has enough
long-term benefits that you'll get decent ROI over many years.