Data access design pattern

Question

I've several cases where a single entity has multiple tables in the underlying database.

When reading or writing I want to handle all of the DB queries with a single class for that object, e.g., the SalesOrder class has a corresponding SalesOrderQuery class and that class uses the underlying tables of Sales_Order_Header and Sales_Line.

Is there a design pattern name for this approach (the class doing the persistance, not the classes making of the entities being persisted)?

• Robert Harvey: Aggregate.

Answer 1

What you describe with one single entity and multiple tables is in fact an aggregate:

• The Sales_Order_Header table contains corresponds to the aggregate root, the order entity
• Sales_Line table corresponds to the line entity belonging to the aggregate, and which is accessed through the root

The design pattern you're looking for, seems to be the repository to manage the objects in memory, which works together with data mappers

If you're looking for a reference, I'd recommend Martin Fowler's excellent book Patterns of Enterprise Application Architecture, which presents all of these in full details, and some other, like unit of work for writing the related objets to the database as part of a db transaction.

• candied_orange: Um really? Sales_Order_Header is the aggregate-root? Not SalesOrder? I thought the idea was to abstract away the low level stuff.
• Christophe: @CandiedOrange I was talking about the tables that represent the entities of the aggregate in the database. I've edited to clarify
• PatrickSJ: @ Christophe I just wanted to clarify my understanding of how what I have now translates to your answer. If my SalesOrderQuery class has the SQL then my SalesOrderMapper wraps the query class and converts the SalesOrder objects to the DB array / fields needed for each SQL query, e.g., if I want to save the sales order then call Repo->save($SalesOrder) which calls SalesOrderMapper->save($data) (and converts object attributes to table columns) which calls the SalesOrderQuery->saveHeader($data) and SalesOrderQuery->saveLine($data) methods?
• Christophe: @PatrickSJ The mapper reads and writes specific objects to the DB without needing a query. The repository is a "mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects" (DDD definition). For this purpose it may use a mapper for specific objects. But it may also use queries to get a group of objects.
• PatrickSJ: @Christophe I'm a bit puzzled on what you said for "it [repository] may use a mapper for specific objects". Somehow or other the repository needs to get the data from the DB. Why wouldn't it go through the mapper if I want a collection of SalesOrders? Or do you mean that the repo has the SQL and it somehow converts the returned array into the collection of SalesOrders (using the SalesOrderMapper?)