Question

I am currently working on rewriting an application to use Data Mappers that completely abstract the database from the Domain layer. However, I am now wondering which is the better approach to handling relationships between Domain objects:

1. Call the necessary find() method from the related data mapper directly within the domain object
2. Write the relationship logic into the native data mapper (which is what the examples tend to do in PoEAA) and then call the native data mapper function within the domain object.

Either it seems to me that in order to preserve the ‘Fat Model, Skinny Controller’ mantra, the domain objects have to be aware of the data mappers (whether it be their own or that they have access to the other mappers in the system). Additionally it seems that Option 2 unnecessarily complicates the data access layer as it creates table access logic across multiple data mappers instead of confining it to a single data mapper.

So, is it incorrect to make the domain objects aware of the related data mappers and to call data mapper functions directly from the domain objects?

Update: These are the only two solutions that I can envision to handle the issue of relations between domain objects. Any example showing a better method would be welcome.

Answer 1

I’m afraid you’ve slightly misunderstood the intention of the Repository pattern.

The Repository is meant to behave like an in-memory collection of a particular domain object, usually an aggregate root:

interface EmployeeRepository {     List<Employee> retrieveBy(Criteria someCriteria);     void store(Employee someEmployee);     int countOf(Criteria someCriteria);     // convenience methods     Employee retrieveById(String id);     Employee retrieveBySSN(String ssn); } 

Clients of this code have no idea whether the collection is in memory, like you’d have for unit-testing, or talking to an ORM mapper in some cases, or calling a stored procedure in others, or maintaining a cache for certain domain objects.

This still doesn’t answer your question. In fact, you could potentially have domain objects have save() and load() methods that delegate to the right repository. I don’t think this is the right way to go because persistence is almost never a part of the business domain, and it gives your domain object more than one reason to change.

Check out this related question for more rambling.

In response to some comments on this answer:

A valid criticism. However, I’m still confused then on how to get a single domain object or a collection of related domain objects when within the context of an existing domain object. – gabriel1836

Let’s say an Employee has many Skills. I see nothing wrong with the Employee Repository calling a Skill Repository like this:

// assume EmployeeRepository talks to a DB via sprocs public Employee retrieveById(String id) {     ResultSet employeeResultSet = this.database.callSproc('PROC_GetEmployeeById',          new Object[] { id });      List<Skill> skills =          new SkillRepository().retrieveBy(new EqualsCriteria('EmployeeId', id));      Employee reconstructed = new EmployeeFactory().createNew().                                   fromResultSet(employeeResultSet).                                   withSkills(skills).                                   build();      return reconstructed;     } 

Another route is instead of calling the Skill Repository, have the Employee Repository call the, in this example, stored procedure to load the result set for skills, then delegate to a Skill Factory to get the list of Skills.

Can’t I make a call to the Repository and whether it issues a call to the data mapper or loads the object in-memory is its concern, isn’t it? – gabriel1836

Exactly right. I usually mock out the entire data tier in my unit tests this way.