I want to do somethign like this: Flag an item in a child collection to be deleted when the parent entity is saved:

pseudo:

Entity B; // = something
Entity A; // = something
A.ChildCollection.Remove(B);
A.Save();
//B is deleted.

But, I don't want to use a seperate unit of work to deal with this.

Why not use the save and delete in one unitofwork?

Otis wrote:

Why not use the save and delete in one unitofwork?

Largely because everything that will be done stems from 1 root entity and nested 1:m relationships and I wanted to avoid using a UOW if it could be done implicitly.

I was thinking of doing this:

Modify my CollectionBase class adding a seperate list of items that need to be deleted. Also in that base add a RemoveForDelete(IEntity); That method will remove it from the primary collection, and add it to the holding collection of items to delete. Then in the parent entity onSave run through the items for deletion in child collections and delete them.

Alternatively, maybe I could finagle a way to have the root entity have a UOW, and my RemoveForDelete method in the CollectionBase would track back to the parent and add the item for removal to its internal UOW. Then the root OnSaveComplete would simply run the UOW.

I know this may seem silly given that I could just use an external UOW. However, as I said I don't want to use a UOW when I only really ever want to keep track of the root entity and Save(true) would then handle the CUDs.

Either way, I might be barking up the wrong tree. I stubbornly don't want to track a UOW externally, and want a 1 line removeX solution that implictly deletes during a full save process of the root.

Think of the UnitOfWork as your collection or root entity. It was meant to be used for such situations. But if you want to modify the generated code / base classes, that's fine too.

Walaa wrote:

Think of the UnitOfWork as your collection or root entity. It was meant to be used for such situations. But if you want to modify the generated code / base classes, that's fine too.

I suppose I am being idealistic. If I can have the entity implicitly handle inserts/updates, I would like deletes from a child collection to be handled implicity, e.g. an add does an insert, why wouldn't Remove have the same potential ability? Yes, I definetely see where it would be a problem if it was a depending record, but that is not my case.

Mainly, I don't want to have to think about or see lines of code that add item for delete to a UOW. Anyway, I'm just being obtuse I guess.