将过程缓存清除迁移到PSR-6缓存池服务

直到现在我们的Doctrine实体通过它们的LifecycleEvents做了缓存清除。结合基于APCu缓存被删除的实体的ID与缓存键常数：因为程序APC方法的将过程缓存清除迁移到PSR-6缓存池服务

/** 
* @ORM\PostPersist() 
*/ 
public function postPersist(LifecycleEventArgs $event) 
{ 
    apc_delete(sprintf(selff::CACHE_KEY, $event->getEntity()->getId())); 
}

这是可能的，但这绝不允许我们升级到PSR-6，因为它使使用应作为服务注入的CacheItemPool。因为我们永远不会在实体中注入缓存池，所以我猜想我们应该为超过一半的实体创建一个EventSubscriber或EventListener。这种可能的开销让我有点害怕。

用户/听众重组是否会增加很多开销，这是否正确？我们是否应该为处理所有事件的所有实体（1..n）添加一个全局侦听器/订阅者，还是为每个实体（n..m）添加一个侦听器/订阅者会更好？

来源

2016-09-28 Rvanlaak

用户/听众重组是否会增加很多开销，这是否正确？

postPersist方法也被添加作为侦听到教义EventManager。 http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html

基于此我猜测不会有重大的开销。

但是，我不会基于这个决定，而是尝试一下。您可以使用Symfony分析器来查看是否存在任何开销以及它有多大。我使用这种比较的非常酷的服务是Blackfire.io。

我们应该添加一个全局监听器/用户的所有实体（1..1）处理所有事件或将是最好添加一个监听器/用户的每一个实体（n..m）？

我会为所有实体创建全局侦听器。如果您需要针对任何特定实体使用不同的缓存逻辑，则始终可以创建单独的案例。

来源

2016-09-29 08:31:02

谢谢，我现在想添加一个监听器，并检查是否存在'postPersist'和'preUpdate'方法。这样无效逻辑可以留在实体层面。生命周期事件还设置了'dateModified'，它没有公共setter。 – Rvanlaak

唯一不同的是，我会做的不是检查方法是否存在，而是创建CacheableEntityInterface并将其应用于要缓存的每个实体。检查对象的类型与检查对象是否有方法相比更加合理。 –

是这样做的，旁边，我使用的Listener注释，这似乎是一个完美的解决方案：http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events。 HTML＃实体监听器 – Rvanlaak

将过程缓存清除迁移到PSR-6缓存池服务

回答

相关问题