This project has moved. For the latest updates, please go here.

SQL Cascading CRUD

Topics: Developer Forum
Jul 27, 2010 at 4:14 AM
Edited Jul 27, 2010 at 4:15 PM

When using the domain model and DDD, business objects often have complex relationships with other business objects. My question is this - When a CRUD operation is executed by a parent object's (Aggregate Root object) DataMapper, how should relationships between the initial object and its related objects be handled (parent-child, one-to-many, many-many, etc)? 

For example, lets say I have a Person object and an Address object in my domain.  A person can have multiple addresses, and address objects are unique (i.e. not shared between Person objects, aka the Person-Address relationship is one-to-many, not many to many).  Lets also assume that I am storing this data using a standard SQL database using Person, Address, and Person_Address tables.  Where should I house the relationship management logic for deleting/updating addresses?  Does it go in the Person datamapper, or should I create a data-layer object specific to the Person_Address table that gets called from the Person datamapper?  Should the logic get pushed down even further, into the actual SQL implementation (i.e. into a stored proc)?

I have some ideas, but I'm really looking for a "best practices" approach for home-grown O/R mapping.

-We wouldn't want to pollute the Domain model with "relationship" objects like PersonAddress, because the parent objects should manage these relationships, but we could create relationship objects in the persistence layer to mask the connections between objects, kindof like Proxy objects (which live in the persistence layer, not the Domain Model).
-Putting the relationship mapping actions into stored procedures/SQL commands redistributes domain logic away from the business objects, which seems bad
-My best guess would be to have the parent/aggregate root DataMapper manage the "relationship" records in any association tables (assuming the db is normalized and association tables exist) using some kind of helper objects that correlate 1-to-1 with the association tables (like a persistence-layer PersonAddressHelper that is responsible for access to the relationship table.  From what I can tell, the old NSK project does not do anything like this, probably because of the simplicity of the Nortwind DB.

**I realize that this would be greatly simplified by using a robust ORM like NHibernate, but that really isn't an option for us right now.

Does anyone have any suggestions/advice/experience dealing with cascading operations when using a custom ORM?

Thanks ahead of time.