在学说中编写任务的存储库相当于什么？

Question

正如API of Doctrine所说：

  

EntityRepository充当具有泛型的实体的存储库   以及用于检索实体的业务特定方法 。

     

此类用于继承，用户可以将其子类化   使用特定于业务的方法编写自己的存储库的类   找到实体。

但是，将我的业务逻辑用于保存实体的正确位置在哪里？

1. 在我的实体本身中放置正确的构造函数？
2. 还将它放入存储库吗？
3. 插入一个新实体与“表单”非常相关，它可以输入数据，所以它应该或多或少地在控制器中？
4. 为控制器创建一个帮助类，以便工作由助手类完成，而不是炸毁我的控制器？
5. 在写这个问题时，我还没想到别的什么？

我更喜欢远离炸毁控制器的解决方案。目前我做了一个由不同控制器调用的辅助类，因为我不确定在哪里放它。

Answer 1

我的解决方案是使用一层管理员，例如UserManager，ArticleManager等。此图层是Service Layer pattern的实现。

管理器层隐藏了与持久化和获取模型对象相关的所有内容 - 也就是说，使用此层的对象不关心模型的存储方式和位置，并且可以随时更改它，而无需重写整个应用程序。 / p>

因此，例如，控制器对Doctrine一无所知。我今天可能正在使用Doctrine ORM进行持久化，但明天它可能是Doctrine ODM或只是普通文件。无论我以后切换到什么，只需要更改管理器层 - 而不是整个应用程序。

以下是典型的UserManager会有的一些方法：

• find($id)
• findBySomething($something)
• save(User $user)
• delete(User $user)

此外，管理器层控制系统的域逻辑，仅在模型对象级别上无法控制。例如，UserManager，当系统要求您保存User时，会检查$user是否为空$plainPassword并对其进行编码并设置为$password 。将此逻辑保留在User模型类中没有意义，因为模型不应该依赖于服务，并且此任务需要密码编码器服务。

您是否在管理层后面使用存储库是您的选择。您可以仅将存储库用于检索方法。但我选择不使用它们，因为它们增加了一些额外的复杂性而对我没有任何好处。由于所有持久性内容都隐藏在管理器层之后，我可以按照我想要的方式重构它。

Answer 2

除了与每个sf2开发人员应该关注的最佳实践相关的实体之外，没有特定的规则来保存实体。

1. 将正确的构造函数放在我的实体本身中？ (You've to keep your entities simple and do not let them know about the persistence layer)

2. 还把它放到存储库中？ (Mainly used for retrieving Entities)

3. 插入新实体与“表单”非常相关 这使得输入数据成为可能，因此它应该更多或更多 在控制器中少了？ 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).

4. 为控制器创建一个辅助类 工作是由助手班完成而不是炸毁我的 控制器？ (Take a look at the Dependency Injection Container , it allows you to create a service for this purpose).

Answer 3

这里DIC开始行动了。你的实体本身应该是愚蠢的，不知道后台的DB是什么..控制器应该保持轻量级...为此，你可以使用依赖注入来创建“服务”。

http://symfony.com/doc/master/book/service_container.html

认为你做的与你的助手类相似，可能会给他们一个调整，以symfony方式做。

-Chris