正如我所学的那样，实体不应该存储任何真实的逻辑，因为它们的用途是存储数据。
另外，我读到控制器不应该有任何“真实代码”，而只在需要时设置一些值并将它们指向实际用于工作的服务。（从控制器中修剪脂肪）。
我理解这些要点，即使我是 Symfony 的新手，我也知道带有“适用于所有事物”的代码的类是非常糟糕的做法（整个 Symfony Book 和 Symfony Cookbook 中的控制器真的看起来像那样）。易于创建，无法维护。而且，如果您遇到必须解耦代码的情况，那么您将获得很多乐趣。但我明白了，因为这些书主要针对新手。
那么，我如何实际创建Entity Type Managers。他们是要走的路吗？
假设我有一个Image实体。我需要ImageManager来删除、更新、调用缩略图服务来创建缩略图等。它在哪里？它在目录结构中到底属于哪里？它不能是未映射的实体，因为它需要注入其中的服务。
您可能会看一下 FOSUserBundle 构建其代码的方式。
它有一个UserManager，FOSUserBundle/Model其中执行不需要任何用户实体存储知识的事情，另一个UserManager在FOSUserBundle/Doctrine其中扩展前者并执行需要存储层知识的事情（它被注入 EntityManager，例如例子）。被FOSUserBundle/Doctrine/UserManager定义为可以从控制器调用的服务。
这种结构的好处是它使测试变得非常容易。单元测试非常FOSUserBundle/Model/UserManager轻量级，不需要模拟教义。单元测试是嘲笑学说的FOSUserBundle/Doctrine/UserManager地方。
我不知道这种事情有最佳实践，但是当我这样做时，我总是将我的经理放在一个Path\To\MyBundle\Manager命名空间中。在我的第三方供应商的项目中，我能找到的唯一一个做同样事情的例子是ElasticaBundle。
关键是您将管理器定义为服务并注入您需要的依赖项。尝试让你的管理器依赖于接口而不是实际的类，以便更容易测试并在必要时更容易在以后更换单个组件。
让您的经理实现一个定义所有公共方法的接口也是一个非常好的主意，就像RepositoryManager我在上面链接到的 ElasticaBundle 中的类所做的那样。