Symfony管理实体

Question

由于我学到了很多困难，实体不应该存储任何真实的逻辑，因为它们的用途是存储数据。

另外，我已经读过控制器不应该有任何“真实代码”，但只在需要时设置一些值，并将它们指向实际用于做工作的服务。 （Trimming fat from controllers）。

我理解这些要点，即使我是Symfony的新手，我知道代码“为所有和所有事情”的类只是非常糟糕的做法（整个Symfony Book和Symfony Cookbook中的控制器真的看起来像那样） 。易于创建，无法维护。如果你遇到需要解密代码的情况，那么你就可以获得很多乐趣。但我明白了，因为这些书主要是针对新人的。

那么，我该如何实际创建实体类型管理器。它们是最好的方式吗？

说我有一个图像实体。我需要 ImageManager 来删除，更新，调用缩略图服务以创建缩略图等。它在哪里？它在目录结构中属于哪里？它不能是未映射的实体，因为它需要注入服务。

Best Practices cookbook article doesn't mention anything like this。

Answer 1

我不知道有这种事情的最佳做法，但是当我这样做时，我总是将我的经理放在Path\To\MyBundle\Manager命名空间中。我在第三方供应商的项目中找到的唯一一个做同样事情的例子就是ElasticaBundle。

关键是您将经理定义为服务并注入所需的依赖项。尝试让您的经理依赖于接口而不是实际的类，以便更容易测试，并在以后更容易更换单个组件。

让你的经理实现一个定义所有公共方法的接口也是一个非常好的主意，正如RepositoryManager类在我上面链接的ElasticaBundle中所做的那样。

Answer 2

您可以查看FOSUserBundle构造其代码的方式。

FOSUserBundle/Model中有一个UserManager，它可以完成不需要任何用户实体存储知识的事情，而FOSUserBundle/Doctrine中的另一个UserManager可以扩展前者并且它做了需要知道存储层的事情（例如，它注入了EntityManager）。 FOSUserBundle/Doctrine/UserManager被定义为可以从控制器调用的服务。

这种结构的好处在于它使测试非常简单。 FOSUserBundle/Model/UserManager的{​​{3}}非常轻量级，不需要模仿教义。 FOSUserBundle/Doctrine/UserManager {{1}}是教诲被嘲笑的地方。