Symfony fetch/persist 面向实体的服务命名约定和最佳实践答案

【问题标题】：Symfony fetch/persist entity-oriented service naming conventions and best practiceSymfony fetch/persist 面向实体的服务命名约定和最佳实践
【发布时间】：2012-07-15 08:02:32
【问题描述】：

一个 Symfony2 应用程序通常有一个实体集合。 Doctrine EntityManager 通常用于获取和持久化这些实体。

实体在整个应用程序的多个地方使用；对于许多实体和每个实体，将给定实体的处理以及获取/持久化服务封装起来是有意义的。

例如，对于User 实体，可能有一个UserService 与fetchUser($user_id) 和persistUser(User $user) 方法（或者可能只是fetch() 和persist(）方法，这只是一个示例）。

一个应用程序最终可以使用许多面向实体的服务来获取和持久化实体。此类服务的接口相似，处理的实体类型不同。

一个应用程序可以包含许多面向实体的服务似乎很常见。因此，命名和构建此类服务的问题是一个常见问题。

对于一个需要创建例如基类EntityService 和子类UserService、WidgetService 和ProductService 的新应用程序来说，感觉是重复的，因为处理这些方面的方法应该是问题解决了。

是否有将此类实体管理相关服务引入 Symfony 应用程序的最佳实践？

感觉这应该是一个已解决的问题，也许有一个很好的设计模式可以遵循。
是否有建议遵循的命名约定？

我观察到，在不同的应用程序中，`UserManager` 和 `UserService` 都被选为服务名称。有通行的约定吗？

【问题讨论】：

因为我有一个类似的问题，并且因为要找到答案，我自己“挖掘”了一些知名的捆绑包，我告诉你“经理”命名约定似乎比“服务”更受欢迎命名约定。

标签： symfony naming-conventions entitymanager

【解决方案1】：

至于命名，我不知道这种情况下的约定，但是有一个管理实体的Doctrine\ORM\EntityManager类，所以我会使用Manager而不是Service。

现在，谈谈实体管理服务：您真的需要这么多服务吗？如果UserService::persistUser() 方法只是持久化用户，为什么要使用自定义服务而不是默认的EntityManager？

另外，您不应该将存储库和持久化方法放在同一个类中。为实体使用自定义存储库不是更容易吗？

【讨论】：