Anemic Domain Model, Business Logic and DataMapper (PHP)

Question

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 protected]','email');

// could easily be this
// $Product = $di->get('product');
// $Product->load('[email protected]','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.

Answer 1

In hindsight, my question should have been "what is business logic". The answer I was looking for was this:

http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic.aspx#_topicpageref_WhatisBusinessLogic

I also found this entertaining analogy: http://www.dougboude.com/blog/1/2008/03/What-IS-Business-Logic-Anyway.cfm

I've put this on cwiki to prevent up-repping

Answer 2

Ideally, your domain objects should be persistence ignorant. Using the repository pattern (which your Mapper implements along with handling the O/R translations), is the preferred route.

Looking at your alternate method, you're getting an instance of an object and then telling it to load itself. It's better to have the object come into existence fully loaded (another reason to consider persistence ignorance).