Data Mapper: An domain object should never call its data mapper?

Question

I'm reading Martin Fowler's Book about enterprise application architecture design patterns, but the German version. So, in my book on page 193 (in case you have it), he writes in German that a domain object (an object of the business logic layer) should not be depending on their Data Mapper. So what does that mean in more detail? If I have a User object and a UserDataMapper class, no method of User shall call a method of UserDataMapper? Or in other words: If there was no UserDataMapper, it must still be possible to work with the User class without getting errors?

Answer 1

In my version (written in English, so the exact translation may differ), the full quote is:

"On occasion you may need the domain objects to invoke find methods on the Data Mapper. However, I've found that with a good Lazy Load (200) you can completely avoid this. For simpler applications, though, may not be worth trying to manage everything with associations and Lazy Load (200). Still, you don't want to add a dependency from your domain objects to your Data Mapper.

You can solve this dilemma by using Separated Interface (476). Put any find methods needed by the domain code into an interface class that you can place in the domain package."

Thus, Fowler suggests you use Separated Interface to get around any package dependency issues.

In practice, these mappings tend to be unobtrusive attributes on fields and methods and such, so that the model is ignorant of the fact that you're using (say) Hibernate, and you can change mappers to something else without breaking everything.

Additionally, sometimes people split the Data Mapper part into the mapping part ("this attribute maps to this column") and a separate service part ("here's how to insert data"), which further separates the concerns.