Scenario: A CSLA BusinessBase class Employee contains a property EmployeeAddress of type Address, where Address is another CSLA BusinessBase class.
Problem:We are able to successfully perform an Insert and update operation using the data portal implementation of the parent and child objects. But we were not able to accomplish a delete operation for the parent and child objects.
When the dataportal_delete() method of the Employee class is called the child_deleteself() method of the Address class is not invoked.
Also we tried calling the FieldManager.UpdateChildren() in the dataportal_delete() method of the Employee class, which is supposed to invoke the child_deleteSelf() method of the Address class and it results in an exception, unlike insert & update operation which perform successfully.
How do we accomplish the delete operation for the above mentioned scenario?
I believe that the pattern most often used is to use a stored procedure to delete the object graph. According to this pattern the parent dataportal_delete calls the store procedure to delete the object graph, leaving the original object and children in this weird invalid state that should not be used again. According to this pattern, child_deleteself is not required to remove the object from the database, since the call to the stored procedure will have removed it.
The other way to do this is to call the Delete method on the business object, and then call Save. If I am not mistaked, this will result in a call to dataportal_deleteself. Here, you probably have to override the Delete method on the parent object, and have it clear the child collection. then calling the UpdateChildren in the parent's dataportal_deleteself method should call into the child_deleteself for each child. Whether you use a stored procedure to delete the whole object graph in the database in the parent's dataportal_deleteself, and just have the child's child_deleteself do nothing, or have each child's child_deleteself call into the database is up to you.
I'm doing this from memory, so some of the details might be a bit fuzzy.
Copyright (c) Marimer LLC