正如Doctrine的API所说:
EntityRepository作为具有泛型的实体的存储库以及用于检索实体的业务特定方法。
这个类是为继承而设计的，用户可以创建它的子类类来使用特定于业务的方法编写自己的存储库查找实体。
但是在哪里是正确的地方把我的业务逻辑保存实体?
- 把正确的构造函数在我的实体本身?
- 将它也放入存储库?
- 插入一个新实体与"表单"非常相关，它使输入数据成为可能，所以它应该或多或少在控制器中?
- 为控制器制作一个helper类，以便工作由helper类完成，而不是炸毁我的控制器? 还有什么是我在写这个问题的时候没有想到的吗?
我更喜欢一个远离炸毁我的控制器的解决方案。目前，我做了一个助手类，由不同的控制器调用，因为我不确定把它放在哪里。
我的解决方案是使用一层管理器，如UserManager, ArticleManager等。这一层是服务层模式的实现。
管理层隐藏了与持久化和获取模型对象相关的一切——也就是说，使用这一层的对象不关心模型如何存储以及存储在哪里，并且可以随时更改，而不必重写整个应用程序。
例如，控制器对Doctrine一无所知。我今天可能会使用Doctrine ORM来实现持久化，但明天可能会使用Doctrine ODM或仅仅是普通文件。无论我以后切换到什么，都只需要更改管理器层—而不是整个应用程序。以下是典型UserManager的一些方法:
-
find($id) -
findBySomething($something) -
save(User $user) -
delete(User $user)
同时，管理者层控制着系统的领域逻辑，这是不能单独在模型对象层上控制的。例如，当被要求保存User时，UserManager将检查$user是否有非空的$plainPassword，并将其编码并设置为$password。将这个逻辑保留在User模型类中是没有意义的，因为模型不应该依赖于服务，而这个任务需要一个密码编码器服务。
是否使用管理层后面的存储库是您的选择。您可以将存储库仅用于检索方法。但我选择不使用它们，因为它们增加了一些额外的复杂性，对我没有任何好处。由于所有的持久性内容都隐藏在管理器层后面，所以我可以稍后按照我想要的方式重构它。
除了与每个sf2开发人员应该关心的最佳实践相关的规则外，没有关于保存实体的特定规则。
-
把正确的构造函数在我的实体本身?
(You've to keep your entities simple and do not let them know about the persistence layer) -
把它也放到仓库吗?
(Mainly used for retrieving Entities) -
插入一个新实体与"表单"非常相关这使得输入数据成为可能，所以应该是更多或在控制器中更少?
Inserting entities in not related to "form". It's ok to put it in your controller, but if you have many lines of code that create and persist your entities, You should then put a shortcut method which contains this logic. (You can also add a base controller for common methods). -
为控制器创建一个helper类工作是由助手类完成的，而不是炸毁我的控制器吗?
(Take a look at the依赖注入容器, it allows you to create a service for this purpose).
DIC在这里起作用。你的实体本身应该是愚蠢的，不知道它的DB在后台…控制器应该保持轻量级。为此，你可以使用依赖注入来创建"服务"。
http://symfony.com/doc/master/book/service_container.html认为你在做类似于你的助手类，可能会给他们一个调整，以symfony-way。
屁股的