我正在开发一个 Symfony 应用程序，但我想我的问题主要与 框架使用。
情况是这样的：
我得到了一个非常轻量级的实体，它实际上甚至不由 ORM 管理，因为它只是用于聚合和传达另一个实体的信息。
我读到我们应该将业务逻辑排除在模型之外，但我也认为它会
如果我在我的轻量级实体中有一个fromXYZ-方法来创建基于“大实体”的实例化的 SPOC，那么证明对我非常有用。
但从技术上讲，这种 from-method 执行的逻辑与我读到的良好实践相矛盾。
那么这会是一个反模式吗？如果是，我将如何以更合适的方式解决这个问题？
【问题讨论】：
标签： oop design-patterns
你说的是static factory method。使用它很好，但它不应该做任何花哨的事情，因为你不能模拟它，所以很难测试你的代码。
如果您觉得您的方法不会在测试中产生任何问题，您可以毫无疑问地创建它。否则，您可以将创建逻辑封装在单独的工厂中。
【讨论】：
您的“轻量级实体”可以称为 DTO。
一种保持术语直截了当的方法。
我不会考虑通过复制字段从另一个对象构造一个对象的业务逻辑，除非业务需求规定了复杂的转换。
fromXYZ 方法的真正问题是它们实现了对XYZ 的依赖。您必须小心这些依赖项指向哪个方向。例如，如果您通过将实体传递给 DTO 来构造 DTO，则该 DTO 现在依赖于应用程序的持久层。如果您随后在服务中使用该 DTO，您的服务层现在对您的持久层具有（传递）依赖关系。这称为紧耦合。
保持业务逻辑与持久性、视图等分离的一种方法是将依赖关系指向另一个方向：进入服务而不是离开服务。
【讨论】：