I have a case (that I will simplify here) where I need to do some business logic on a delete. When a parent is deleted, a great-grandchild of the parent may need to "return a part to inventory" which means it needs to issue inserts and updates to our parts tables. I would like to do this all in the delete transaction, but don't see a good way to do that. The .Save() call to DataPortal_Delete does not pass the business object across the across the data portal; so I don't have access to the object and all its children where I want to begin my transaction. Should we pass our parent object across the dataportal ourselves?
Currently, we override Delete() and we .Remove the great-grandchild objects if we have them, issue a .Save(), then issue the base.Delete() and let the UI's call to .Save() delete the root object (we use cascade deletes in the database to delete all the child records).
Is there a better way to do complicated stuff on the children when the parent is getting deleted?
Remember that CSLA has two delete modes: deferred and immediate.
If you use DataPortal.Delete(), that's immediate mode, and only the criteria is passed through the data portal to the DataPortal_Delete() method.
But if you use deferred delete, you'll retrieve the business object with a fetch, interact with it, including possibly calling Delete() on the object (which marks it for deletion). And in this case when you call Save() on the object, you'll end up in DataPortal_DeleteSelf() with full access to the object, just like you would in DataPortal_Insert() or DataPortal_Update().
All that is true for root objects. For child objects, only deferred delete is available, because the child object is always deleted as part of the root object being saved (regardless of whether the root is doing an insert, update or delete).
That isn’t really an “incorrect pattern” for
mainstream cases. I actually do that all the time.
But if you have more complex behaviors, then it may not work for
you – and I think your scenario is one where you can’t just
delegate the call to a simple implementation.
Rocky
Copyright (c) Marimer LLC