Yes, as Walla said - if you want to do In-Memory Delete, and have the removed children be deleted when you save - you need to use RemovedEntityTrackers.
It's quite simple:
myCustomer.Orders.RemovedEntitiesTracker = New OrderCollection
myCustomer.Orders.Remove(myOrderToDelete)
Dim myWork as New UnitOfWork
myWork.AddForSave(myCustomer, True)
myWork.AddCollectionForDelete(myCustomer.Orders.RemovedEntitiesTracker)
myWork.Commit()
Hope this helps!
Ryan
PS. Remember, if you delete multiple EntityTypes within the same Unit of Work- you must add them to the UnitOfWork in the proper order (children first, then parents) to avoid SQL dependency errors.
I've written a DeleteTracker class that tracks all RemovedEntitiesTracker Collections across n-Level child entity relationships. When saving your UnitOfWork you simply call myDeleteTracker.SaveWith(myWork); which will automatically detect all dependencies (even though your entities are no longer part of an EntityGraph), determines proper commit order, and deletes inside the Unit of Work. This way, I support in-memory deletes (which, of course, can be cancelled by the user)... and I don't have to worry about the order in which to commit. I don't even need to know the specifics about how deep down into the EntityGraph the user deleted entities. It just works.