views:

149

answers:

1

If my understanding of Aggregate Roots is correct, the root should be responsible also for deleting one of its "children". That would seemingly translate into something like this:

order.removeOrderLine(23);

Which would effectively remove it from the collection. However, how is this persisted? Is my ORM's UnitOfWork supposed to detect that something went missing in that collection, and then delete it from the database?

Should I have removeOrderLine a method of the OrderRepository instead?

+3  A: 

Your Unit of Work should usually take care of this, but it depends on its implementation, specifically on the way it detects changes. Some unit of work implementations (i.e. Hibernate) keeps a copy of the aggregate before you changed it, so at the end of business transaction (when you call something like unitOfWork.PersistAll()), it tries to match current version of all objects (and collections) against the original version.

Other way is to have your domain entities more coupled with your unit of work so that the entity notified the unit of work when something changes (i.e. the order.removeOrderLine method would notify the unit of work about the change).

There are multiple ways how to implement UoW change detection. Have a look at several implementations for hibernat for inspiration.

Tomas
In terms of collection change tracking, I have a good experience with simply implementing custom collection that captures all calls to "Add" and "Remove" methods and stores the objects added / removed in 2 internal "collections" - 1 collection for added items, 1 collection for removed items. The UoW can then simply ask the collection what changed.
Tomas