Php – Anemic Domain Model, Business Logic and DataMapper (PHP)

design-patternsdomain-modelormPHP

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('me@email.com','email');

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

Best Answer

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

Related Topic