Datamapper – doctrine2 best practice, should entities use services?

I answered a similar question: using the data mapper pattern, should the entities (domain objects) know about the mapper? However, it's universal. I'm really interested in how to do something with doctrine2

This is a simple example model: each thing can have one vote from the user. The user can cast multiple votes, but only the last vote count Because other data (msssage, etc.) is related to voting, when placing the second voting, the original voting cannot be updated only, it needs to be replaced

At present, thing has this function:

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

Voting is responsible for building relationships:

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

In my opinion, ensuring that users only vote for the last time is something that should be ensured, not some service layer

So in order to keep the new thing function in the model:

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

So how do I remove votes from the domain model? Should I relax that vote:: setthing() accepts null? Should I use some kind of service layer that thing can use to delete voting? Once the votes begin to accumulate, that foreach will slow down - if you use the service layer to allow things to search for votes without having to load the entire collection?

I absolutely prefer to use the light service layer; But is there a better way to deal with things like doctrine2, or am I moving in the right direction?

Solution

I voted for service I often try to add as much logic as possible to the entity itself, and just make myself frustrated Unable to access entitymanager, you can't execute query logic at all. When you only need a few records, you will find that you use a lot of O (n) operations or delay loading the whole relationship set (this is super. It's lame compared with all the advantages provided by DQL

If you need some help to overcome the idea that anemia domain models are always anti patterns, please refer to Matthew Weier o'phinney or this presentation of this question

Although I may misunderstand the terminology, I do not fully believe that entities must be the only objects allowed in the domain model It's easy for me to think that the sum of entity objects and their services constitutes the model I think when you end up writing a service layer that pays little attention to separation of concerns, antipatterns will appear

I often think of having all entity objects proxy some methods to the service layer:

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

However, because doctrine doesn't have any type of object callback event system, I haven't found an elegant way to inject service objects