Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
I found the answer to my poorly phrased question: codeproject.com/KB/architecture/… –  sunwukung Mar 10 '11 at 9:45
add comment

2 Answers

up vote 1 down vote accepted

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

share|improve this answer
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.