Doctrine2 最佳实践，实体应该使用服务吗？

Question

我不久前问过类似的问题： 使用数据映射器模式，实体（域对象）应该了解映射器吗？但是，它是通用的，我真的很感兴趣如何使用 Doctrine2 专门完成一些事情< /强>。

下面是一个简单的示例模型：每个 Thing 都可以有来自 User 的 Vote，一个 User 可以投票超过一次投票，但仅最后一次投票有效。由于其他数据（Msssage等）与Vote相关，因此当放置第二个Vote时，将原始Vote > 不能只是更新，而是需要更换。

目前 Thing 具有此功能：

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

并且 Vote 负责建立关系：

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

在我看来，确保 User 仅具有最后一个 < code>投票计数是Thing应该确保的事情，而则不然一些服务层。

因此，为了将其保留在模型中，新的 Thing 函数：

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

那么如何从域模型中删除 Vote ？ 我应该放松一下吗投票::setThing() 接受NULL？我是否应该涉及某种可以让 Thing 用来删除投票的服务层？一旦投票开始累积，foreach 就会变得很慢 - 如果使用服务层来允许 Thing 搜索 Vote 而无需必须加载整个集合？

我绝对倾向于使用轻服务层；但是，有没有更好的方法来使用 Doctrine2 处理此类事情，或者我正朝着正确的方向前进吗？

Answer 1

我投票给服务层。我经常努力尝试在实体本身上添加尽可能多的逻辑，这让我自己感到沮丧。如果无法访问 EntityManager，您根本无法执行查询逻辑，并且您会发现自己在只需要几条记录时使用大量 O(n) 操作或延迟加载整个关系集（这是超级的）与 DQL 提供的所有优势相比是蹩脚的）。

如果您需要一些帮助来克服贫血域模型始终是反模式的想法，请参阅 Matthew Weier O'Phinney 的演示或这个问题。

虽然我可能会误解术语，但我并不完全相信实体必须是域模型中允许的唯一对象。我很容易认为实体对象及其服务的总和构成了模型。我认为当您最终编写一个几乎不关注关注点分离的服务层时，就会出现反模式。

我经常考虑让所有实体对象将某些方法代理到服务层：

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

但是，由于 Doctrine 没有任何关于对象水合作用的回调事件系统，我还没有找到一种优雅的方式来注入服务目的。

Answer 2

我的建议是将所有查询逻辑放入 EntityRepository 中，然后从中创建一个接口，就像这样：

class BlogPostRepository extends EntityRepository implements IBlogPostRepository {}

这样您就可以在服务对象的单元测试中使用该接口，并且不需要依赖于 EntityManager。