Finer control over persistence process

jureleskovec posted on Wednesday, August 05, 2009

V have just ran into an interesting issue with persistence process. In general our 'DataPortal_Update' method looks like:
1) Call the update sproc for the root/parent object.
2) Update the root's children (FieldManager.UpdateChildren).

For most (simple) cases this works fine since the corresponding database tables of the root's children have foreign keys relating to the root's database record.


This is mostly true for cases where you have 'simple' object trees (root has children, each child can further has children, ...). In more complex cases object trees aren't sufficient you would need a more complex object graph (which csla doesn't support). For example, an object from a sub tree would need to reference another object in another sub tree. In our applications such cases are ubiquitous and luckily, we found nice workaround for the issue.

In such a complex cases sometimes the order of persisting objects is important. You can update children in an arbitrary orders using 'DataPortal.UpdateChild' method. But in even more complex cases this is not enough. We have the case where we would like to first delete items in list A (that were marked for deletion), then update some others and finaly update items in list A.

For such task I would expect something like 'DataPortal.UpdateDeletedChildren/UpdateNewChildren/UpdateDirtyChildren' besides the 'DataPortal.UpdateChild' method.


-- Jure

RockfordLhotka replied on Wednesday, August 05, 2009

For such cases you need to override the BLB Child_Update() method and provide your own implementation.