...moved into its own thread. My bad.

Is there an official best practice for managing a parent entity's deleted status?

So if I have an Order entity that has a collection of orderLineItem entities, I can let users delete line items by clicking delete. The app uses the RemovedEntitiesTracker to hold them temporarily while we confirm delete or whatever.

But what about deleting the Order? I want to work with an Order entity in my UI, mark it for deletion and then actually clobber the database rows in my DAL. To do that, I need a way to temporarily mark it for deletion.

I'm not talking about storing isDeleted in the database, just in the business logic while we figure out if that is really what the user wants to do .

I know I can add an isDeleted flag to the template, but is there a better, officially recommended way to do this? isDirty and isNew are really useful. I was surprised to find that there is no corresponding isDeleted and that omission makes me wonder if I'm the one missing something.

I'm not clear on why you would want to mark it for deletion. Once you know it needs to be deleted, wouldn't you just delete it right then and there?

Phil

psandler wrote:

I'm not clear on why you would want to mark it for deletion. Once you know it needs to be deleted, wouldn't you just delete it right then and there?

Phil

No, sometimes you might want a soft delete, and allow the user to undelete.

Recommended reading: http://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx

daelmo wrote:

Recommended reading: http://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx

it depends what type of applications you are building,

in a finanical application, you wouldn't want to delete any data!

You haven't read the article I think, as it suggests 'archiving' instead of Isdeleted flags. I.o.w.: you don't delete any data, you just move it to an archive, as that's what you're doing anyway: the archive of 'deleted' (but now hidden) rows is merged with your active dataset. Which has the downside that unique constraints, FK constraints etc. don't work.

I wasn't really asking about soft deletes, but rather how to mark an entity for deletion while you are working with it in the ui or business logic but aren't quite ready to persist it to the dal.

Maybe you have some validation logic that needs to fire between the time the user clicks "delete this order" and the order actually deletes, or maybe you have an ad hoc collection of order entities that need to be flagged for deletion, unflagged, flagged again, double checked, and then finally deleted in one fell swoop.

I can do a bunch of stuff in my ui, confident that my dirty entities get marked so, then hand them off to my data repository for persisting. I can't do that with stuff I want to delete.

Either way, it was a pattern I used a lot with my own ORM system and its absence was a bit suprising, as we have isDirty.

In that case, use a UnitOfWork(2) instance and add the entity for deletion to that.

As LLBLGen Pro is a system which is build around the fact that you tell the system what to do with the entity (e.g. save, delete, fetch) it awaits your calls. So there's no central context/session which controls the universe, you've to tell the system what to do. The unitofwork can help with that, as it can be a central unit inside a form/method /class where you want to track work to do and commit in 1 go.

Collections can contain removal trackers as well (see documentation about entity collections) which track entities which are removed. You then can add those in 1 go to the unitofwork or delete them using the tracker collections.