Is there a better way than this to handle a complicated delete?

Is there a better way than this to handle a complicated delete?

Old forum URL: forums.lhotka.net/forums/t/6773.aspx


RobKraft posted on Thursday, April 09, 2009

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?

RockfordLhotka replied on Thursday, April 09, 2009

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).

RobKraft replied on Monday, April 13, 2009

Thanks Rocky!  The few places where we are using DataPortal_DeleteSelf() we actually have it calling DataPortal.Delete().  I don't know how we stumbled into that incorrect pattern but we will correct it so that we can use DataPortal_DeleteSelf() for the complicated things we need to do.

RockfordLhotka replied on Monday, April 13, 2009

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