Doctrine 第2条动态限制社团

所以我有以下几点

/** @Entity */
class Job {

    /** @OneToMany(targetEntity="Invoice" ...) */  INVERSE SIDE
    protected $invoices;

    public function getInvoices() {
        return $this->invoices;
    }
}

理想情况下，我希望根据ACL筛选返回的发票。这就是我目前的想法

一,。我可以编写存储库方法，并使用将ACL逻辑转换为DQL

// in some client code....

// $constraint would contain the DQL logic needed to restrict association returned   
$constraint = new InvoiceAccessConstraintFactory($user);


$jobs = $jobRepository->findAllSatisfying(array('status' => 'SomeStatus'), $constraint);

我对这种方法的问题是，我觉得对于一个人来说，它很难维护，但我认为它在性能方面是相当好的

二,。使用后加载事件侦听器创建PersistedCollection的自定义代理，该代理包含发票的原始PersistedCollection和自定义迭代器扩展FilterEditor

PostLoad Listener 
public function applyACL($args){
    $job = $args->getEntity(); 

    $proxy = new InvoiceAccessProxy($job->getInvoices(), array('iteratorClass' => 'InvoiceAccessFilter', 'user' => $user)); 


    $job->setInvoices($proxy);
}

... so that in client code
foreach($job->getInvoices() as $invoice) {
    // filtered through accept method in InvoiceAccessFilter
}

但我不确定这一点，因为PersistedCollection的代理是不可能的。但我确实喜欢访问$job->getInvoices并根据上下文返回不同的结果集

三,。我在某处阅读了Doctrine2文档，其中提到可以使用实现自定义AST Walker来实现访问控制，但我找不到一个示例。我认为这将是一个挑战

4。。。。。寻找其他想法

我想这篇文章是因为我需要能够根据不同的上下文以不同的方式显示相同的数据

---

所以我只是在寻找任何人能给我的建议。。。示例、阅读材料、想法……

我认为这是合乎逻辑的解决方案