我目前正在Symfony 3中进行开发，我想知道以下情况下的最佳实践是什么(如果有的话)：
假设我有客户和订单实体，每个订单都链接到一个客户。如果我想按客户计算订单总额，最好的方法是什么？
- 客户端类中的一个函数，用于解析客户端的订单以求和并返回结果
- 订单存储库中的函数，将客户端作为参数并返回标量结果(…SUM(order.value)WHERE order.client=：client)…)
- 存储库中的一个函数，它返回客户端的所有订单，然后对控制器中的值求和
感谢您的帮助，祝度过美好的一天
尽管这个短语很流行，但并不存在客观的"最佳实践"。它总是主观的，总是取决于你的具体问题。这就是为什么这类问题往往会遭到反对、否决和关闭。
- 客户端类中的一个函数，用于解析客户端的订单以求和并返回结果
从领域驱动的设计角度来看，这将是理想的。业务实体中的业务逻辑。问题是你认为一个客户会累积多少订单，因为这种方法需要加载给定客户的所有订单。几十份订单？可能很好。几千个订单？可能会开始放慢速度。也许您可以从这种方法开始，然后随着系统的发展进行重构？
- 订单存储库中的函数，将客户端作为参数并返回标量结果(…SUM(order.value)WHERE order.client=：client)…)
这似乎会非常有效。另一方面，它开始将一些客户端功能泄漏到订单域。如果你最终发现这些特殊功能分散在各处，可能会变得很难维护。但如果这是唯一的一个，那么它可能是好的。
- 存储库中的一个函数，它返回客户端的所有订单，然后对控制器中的值求和
抓取所有订单与第一个解决方案具有相同的缩放问题。你真的需要完整的订单来汇总吗？求和到底意味着什么？将业务功能放在控制器中通常不是一件好事。如果你也需要在其他地方计算总和呢？另一方面，它是Symfony，相当多的Symfony应用程序确实有相当胖的控制器，具有大量的业务逻辑，并且运行良好。因此，如果它适合应用程序的其他部分，这可能是最好的方法。
虽然您没有提到，但创建ClientOrder服务也是可能的。
但归根结底，这真的是你的决定。任何神奇的最佳实践都无济于事。我建议写一些测试，只是为了让可能的重构更容易，然后选择一种满足您当前需求的方法，继续前进
请注意，以下只是我的意见，因为官方学说最佳实践中没有提到这一点。
客户端类中的一个函数，用于解析客户端的订单以求和并返回结果
这将导致从数据库加载所有相关订单，除非您将集合标记为"extra-lazy"(extra-Lzy Associations)。但在我看来，你不应该这样做，只要你无论如何都不处理整个收藏。
订单存储库中的一个函数，将客户端作为参数并返回标量结果(…SUM(order.value)WHERE order.client=：client)…)
这应该是一条路。您将所有的"繁重工作"都放到Repository类中，您的应用程序不需要知道Repository是如何获得订单数的。此外，您不会将实体类与其他功能混为一谈(imo它们应该只包含数据，更具体的请求应该由存储库处理)。
存储库中的一个函数，它返回客户端的所有订单，然后将控制器中的值相加
这将加载与变体1类似的所有实体，所以除非您无论如何都想处理所有实体，否则不要这样做。