php - 什么相当于在条令中编写任务的存储库？

Question

作为API of Doctrine说:

An EntityRepository serves as a repository for entities with generic as well as business specific methods for retrieving entities.

This class is designed for inheritance and users can subclass this class to write their own repositories with business-specific methods to locate entities.

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

1. 将正确的构造函数放入我的实体本身？
2. 是否也将其放入存储库？
3. 插入一个新的实体与使输入数据成为可能的“表单”非常相关，所以它或多或少应该在 Controller 中？
4. 为 Controller 创建一个辅助类，以便工作由辅助类完成，而不是破坏我的 Controller ？
5. 写这个问题时还有什么我没有想到的吗？

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

Answer 1

我的解决方案是使用一层管理器，如UserManager、ArticleManager 等。这一层是Service Layer pattern 的实现。 .

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

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

这是典型的 UserManager 具有的一些方法:

• 查找($id)
• findBySomething($something)
• 保存(用户 $user)
• 删除(用户 $user)

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

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