3

I asked a similar question a while back: Using the Data Mapper Pattern, Should the Entities (Domain Objects) know about the Mapper? However, it was generic and I'm really interested in how to accomplish a few things with Doctrine2 specifically.

Here's a simple example model: Each Thing can have a Vote from a User, a User may cast more than one Vote but only the last Vote counts. Because other data (Msssage, etc) is related to the Vote, when the second Vote is placed the original Vote can't just be updated, it needs to be replaced.

Currently Thing has this function:

public function addVote($vote)
{
  $vote->entity = $this;
}

And Vote takes care of setting up the relationship:

public function setThing(Model_Thing $thing)
{
  $this->thing = $thing;
  $thing->votes[] = $this;
}

It seems to me that ensuring a User only has the last Vote counted is something the Thing should ensure, and not some service layer.

So to keep that in the Model, the new Thing function:

public function addVote($vote)
{
  foreach($this->votes as $v){
    if($v->user === $vote->user){
      //remove vote
    }
  }
  $vote->entity = $this;
}

So how do I remove the Vote from within the Domain Model? Should I relax Vote::setThing() to accept a NULL? Should I involve some kind of service layer that Thing can use to remove the vote? Once the votes start accumulating, that foreach is going to be slow - should a service layer be used to allow Thing to search for a Vote without having to load the entire collection?

I'm definitely leaning toward using a light service layer; however, is there a better way to handle this type of thing with Doctrine2, or am I heading in the right direction?

Community
  • 1
  • 1
Tim Lytle
  • 17,549
  • 10
  • 60
  • 91

2 Answers2

7

I vote for the service layer. I've often struggled with trying to add as much logic on the Entity itself, and simply frustrated myself. Without access to the EntityManager, you're simply not able to perform query logic, and you'll find yourself using a lot of O(n) operations or lazy-loading entire relationship sets when you only need a few records (which is super lame when compared to all the advantages DQL offers).

If you need some assistance getting over the idea that the Anemic Domain Model is always an anti-pattern, see this presentation by Matthew Weier O'Phinney or this question.

And while I could be misinterpreting the terminology, I'm not completely convinced that Entities have to be the only objects allowed in your Domain Model. I would easily consider that the sum of Entity objects and their Services constitutes the Model. I think the anti-pattern arises when you end up writing a service layer that pays little to no attention to separation of concerns.

I've often flirted with the idea of having all my entity objects proxy some methods to the service layer:

public function addVote($vote)
{
   $this->_service->addVoteToThing($vote, $thing);
}

However, since Doctrine does not have any kind callback event system on object hydration, I haven't found an elegant way to inject the service object.

Community
  • 1
  • 1
Bryan M.
  • 17,142
  • 8
  • 46
  • 60
  • I will checkout the links - I agree that the Service Layer can (should) be considered part of the Model. I think Fowler says the same in his Anemic Domain Model post). While I'd (currently) favor letting the entities handle adding the vote internal, I'd proxy to the service layer for finding/deleting a vote - instead of the crazy search through the collection. I guess the question is - how to inject the service object. Perhaps a static function like `$em->getRepository()`? – Tim Lytle Dec 16 '10 at 22:13
  • Got a chance to go through that presentation - really good information. Reminds me of some Zend Framework architecture (no surprise there). Still processing how a heaver service layer would effect ease of unit testing. Again, great link. – Tim Lytle Dec 17 '10 at 03:08
  • I'm interested in you approach here. I'm also toying with the idea of having a service as a property of my entity and then implementing methods like 'save' on the entities themselves (which use the service to handle the persistance). This seems a bit activeRecord(ish) which is why I habn't done it. Is the alternative to use a Service Object but pass the entities INTO in instead? – calumbrodie Jun 24 '11 at 08:36
  • @kissmyface Your entity is just a Data Container, you should not rely on it this kind of dependence. Even if you use some type of dependency injection, you will end up having an entity full of methods to manipulate data and often repeating the method of its own class of service. Why instead of having the class of service within your entity, you do not have their entity within the class of service? – jonathancardoso Aug 09 '11 at 15:52
6

My advice would be to put all the query logic into an EntityRepository and then make an interface out of it sort of like:

class BlogPostRepository extends EntityRepository implements IBlogPostRepository {}

that way you can use the interface in your unit-tests for the service objects and no dependency on the EntityManager is required.

beberlei
  • 4,297
  • 1
  • 23
  • 25