Question

使用https://insight.sensiolabs.com扫描/检查我的代码，我收到以下警告：

The Doctrine Entity Manager should not be passed as an argument.

为什么在服务中注入实体管理器是一种不好的做法？什么是解决方案？

Answer 1

关于存储库无法持久化实体的注释。

class MyRepository extends EntityRepository
{
    public function persist($entity) { return $this->_em->persist($entity); }
    public function flush  ()        { return $this->_em->flush  (); }

我喜欢让我的存储库或多或少地遵循“标准”存储库接口。所以我这样做：

interface NyRepositoryInterface
[
    function save($entity);
    function commit();
}
class MyRepository extends EntityRepository implements MyRepositoryInterface
{
    public function save  ($entity) { return $this->_em->persist($entity); }
    public function commit()        { return $this->_em->flush  (); }

这允许我定义和注入非教义存储库。

您可能反对必须将这些帮助程序函数添加到每个存储库。但我发现有点复制/粘贴是值得的。特征也可能对此有所帮助。

这个想法是脱离实体经理的整个概念。

Answer 2

我目前正在开展一个相当大的项目，并且最近开始使用可以改变数据的存储库的方法。我真的不明白将EntityManager作为依赖注入的动机，这与将ServiceManager注入任何类一样糟糕。人们试图证明这只是一个糟糕的设计。诸如persist，remove和flush之类的操作可以被抽象为类似于AbstractMutableRepository，而每个其他存储库都可以继承。到目前为止，它已经做得很好，使代码更易读，更容易进行单元测试！向我展示至少一个具有EM注入的服务示例，并且单元测试正确显示？能够进行EM注入的单元测试更多的是测试实现而不是其他任何东西。结果是你最终为它设置了这么多嘲讽，你真的称它为一个不错的单元测试！这是一个代码覆盖击球手，仅此而已！

在服务中注入Doctrine Entity Manager - 不好的做法？

2 个答案: