3

正如Doctrine 的 API所说：

EntityRepository 用作实体的存储库，具有用于检索实体的通用方法和业务特定方法。

此类是为继承而设计的，用户可以对此类进行子类化，以使用特定于业务的方法编写自己的存储库来定位实体。

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

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

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

4

3 回答 3

4

我的解决方案是使用一层管理器，如UserManager，ArticleManager等。这一层是服务层模式的实现。

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

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

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

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

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

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

于 2013-03-16T10:19:23.137 回答
1

除了与每个 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 , it allows you to create a service for this purpose).

于 2013-03-16T10:09:29.813 回答
0

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

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

认为您正在使用您的助手类进行类似的操作，可能会给他们一些调整以使用 symfony 方式进行操作。

-克里斯

于 2013-03-16T09:54:06.343 回答