2011-08-10 30 views
1

我想创建在我的代码的“API状”层,有效地警戒线断,更高级别的代码数据库访问。例如,我可能有以下功能:如何“defang”一个Doctrine2实体?

class MyApi { 
    private $my_user_id; 
    function getContacts() { 
     $contacts = $em->getRepository('Contacts')->findByOwner($this->my_user_id); 
     $em->clear(); 
     return $contacts; 
    } 
    function getGroups() { 
     $groups = $em->getRepository('Groups')->findByOwner($this->my_user_id); 
     //hydrate each group's contacts list 
     foreach ($groups as $group) { 
      $group->getContacts(); 
     } 
     $em->clear(); 
     return $groups; 
    } 
} 

我使用$ EM->明确的()的返回他们之前分离从EntityManger的实体,所以我的观点不会意外修改管理实体。然而,当我想比较两个连续的API函数返回的实体时,我遇到了问题。理想情况下,我想的视图/控制器包含:

$my_contacts = $myapi->getContacts(); 
$my_groups = $myapi->getGroups(); 

foreach($my_groups as $group) { 
    foreach ($my_contacts as $contact) { 
     if ($group->getContacts()->contains($contact)) { 
      echo "{$group->getName()} contains {$contact->getName()}!<br/>"; 
     } else { 
      echo "{$group->getName()} does not contain {$contact->getName()}!<br/>"; 
     } 
    } 
} 

但是,由于我分离所有从EntityManager的联系人的在getContacts API呼叫的结束,通过$group->getContacts()返回的对象是不同 PHP对象比那些由$api->getContacts()返回,所以功能不能正常工作。

我一定不放弃的的EntityManager提供好处“defanging”我的实体,使他们有效地只读,任何选项? (如代表同一数据库条目是相同的对象,能够进一步水合物相关的对象,他们已经通过从API回来后,等所有的管理实体)

回答

1

为什么你会担心你的观点会进行将被提交回数据库的更改?如果您的观点不了解EM(他们不应该),他们对实体所做的任何更改将在请求结束时消失。

我能想到的唯一的另一种选择是滋润你的结果时,他们注定要被输送到视图脚本阵列。但是,这会放弃很多方便的功能。

+0

我不担心我的视图会自己刷新任何东西,但我担心控制器调用“getter”API动作,更改返回的实体,然后调用第二个API动作的可能性涉及冲洗EM。第二个API调用将写入我预期的更改,以及在API调用之间进行的任何意外更改。我可以谨慎地不要在API之外进行更改,但API的重点在于保护自己免于错误,并且让控制器不必担心实体与EM的关系。 –

+0

另一种选择是在将实体传递给视图之前分离您的实体。当然,您需要注意以下几点:A)您已经提取了您需要的所有关联,以及B)您的分离操作会在所有关联中级联。 – timdev

0

也许这是一个有点晚,但它可以为任何人谁仍然需要对这个问题的答案非常有用......

我觉得这是在这里失踪领域驱动设计的原则:Command Query Separation
中的每个对象只能有两种样的方法:

doSomething() { 
    //this kind of method can change the internal state 
} 

getSomething() { 
    //this kind of method NEVER changes internal state 
} 

牢记正确的MVC,意见应该只需要获取的方法和他们永远不能改变任何事情。
卸下你的实体是没有必要的,也无须担忧,如果仅保留CQS和MVC的初衷。