I've implemented a rudimentary ORM layer based on DataMapper (I don't want to use a full blown ORM like Propel/Doctrine - for anything beyond simple fetch/save ops I prefer to access the data directly layer using a SQL abstraction layer).
Following the DataMapper pattern, I've endeavoured to keep all persistence operations in the Mapper - including the location of related entities.
My Entities have access to their Mapper, although I try not to call Mapper logic from the Entity interface (although this would be simple enough). The result is:
// get a mapper and produce an entity $ProductMapper = $di->get('product_mapper'); $Product = $ProductMapper->find('email@example.com','email'); // could easily be this // $Product = $di->get('product'); // $Product->load('firstname.lastname@example.org','email'); //.. mutate some values.. save $ProductMapper->save($Product) // uses __get to trigger relation acquisition $Manufacturer = $Product->manufacturer;
I've read some articles regarding the concept of an Anemic Domain model, i.e. a Model that does not contain any "business logic". When demonstrating the sort of business logic ideally suited to a Domain Model, however, acquiring related data items is a common example.
Therefore I wanted to ask this question: Is persistence logic appropriate in Domain Model objects? Or rather - what logic goes into the Entity classes once the persistence and relation handling is pushed into the mapper.