所以我有以下内容。
/** @Entity */
class Job {
/** @OneToMany(targetEntity="Invoice" ...) */ INVERSE SIDE
protected $invoices;
public function getInvoices() {
return $this->invoices;
}
}
理想情况下,我想过滤针对ACL返回的发票。所以这些是我到目前为止的想法。
1。)我可以编写Repository方法,并将我的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);
我对这种方法的问题在于,我觉得它很难维护,但它会我认为在性能上非常好。
2.。)使用PostLoad事件监听器为PersistedCollection创建一个自定义代理,其中包含发票的原始PersistedCollection和扩展FilterIterator的自定义Iterator。
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()并让它根据上下文返回不同的结果集。
3.。)我已经在Doctrine2文档中读到了实现自定义AST Walkers可用于实现访问控制的地方,但我一直无法找到示例。我认为这将具有挑战性。
4。).....寻找其他想法
我想这篇文章是因为我需要能够根据众多环境以不同方式显示相同的数据。
所以我只是在寻找任何人可以给出的建议......例子,阅读材料,思想......