Why not updating objects returned from the server instead of invalidating the reference?

HiPerFreak posted on Tuesday, November 24, 2009

Hi Rocky!

I spent some time with CSLA.NET recently and it looks quite promising to me. As I went through the architecture of CSLA, I was asking myself the question: When you call DataPortal.Update for example, you can only return a new object because the objects goes over the network - that's clear so far. BUT wouldn't it be possible, to update the existing objects on the client (I mean copying the state of the newly returned object graph to the already existing object graph)? It seams to me that one might reuse some code of the Undo feature which seems to be conceptually a similar problem.

I would really love to hear your comments on this topic. Maybe you could include this topic in the next edition of your book, because I guess I am not the only one who is interested in it.

Best regards,
Daniel

JoeFallon1 replied on Tuesday, November 24, 2009

This has been discussed dozens of times over the years. It is an architectural decision. Updating an object graph in place is quite a bit more difficult than it sounds. A single object may be simple but what if they have child collections which have child collections? Much harder.

I am sure others can elaborate more on this point.

Joe

 

RockfordLhotka replied on Tuesday, November 24, 2009

There is a Csla.DiffGram sample in the Samples download that shows one way to do this.

The core problem is object identity. There must be some way to reliably identify an object instance, even if that instance has been destroyed and recreated a couple times.

Most newly created business objects have no identifier - not until they are inserted into the database where they get a primary key. But that primary key has to be merged back into the object in memory - which means we need to be able to find that object.

So what the Csla.DiffGram sample does is extend BusinessBase to add a generated "id" value for every object, thereby giving every object a unique identifier so we can find it later.

But the DiffGram sample is very limited. It doesn't express the full object graph on the server, so there's no concept of parity between client and server code. It doesn't reintegrate things like broken rules. In short, it gives up most of the really cool parts of the mobile object concept and provides more of a DataTable model.