我应该把东西注入我的实体吗？

Question

使用IoC容器时，将其他类注入其中是否被认为是好的设计？即持久性等级

Answer 1

这是Spreadsheet Conundrum：你写的是repository.store（entity）还是entity.storeIn（repository）？

每个都有其优点。我通常倾向于喜欢repository.store（实体），主要原因是我保持我的实体的方法以域为中心。写pen.dispenseInkOnto（Surface）是有道理的，因为这就是笔的作用。写pen.storeIn（penRepository）会有点意义。

缺点是您需要提供对实体类的内部访问到持久性类的权限。除了getter，它引入了与entity.storeIn（）相同的问题，我会使用友元类，包受保护的访问，内部访问或某种类型的friend class pattern来限制对内部的访问仅限于那些谁需要它。

对于类的一般注入，在pen.dispenseInkOnto（Surface）示例中，您可以很好地使Surface成为接口并使用注入。只要您注入其他实体，值对象或服务，我就认为没有问题。

Answer 2

一般来说，我建议不要这样做。实体就是这样，应该代表您核心域的一些可识别和重要的部分。他们应该有一个责任，并且非常非常善于这样做。如果实体需要额外的服务来完成一项任务（比如坚持自己），那么你就会开始让像基础设施这样的东西进入你的领域。即使发票能够计算其账单价值的概念也不一定是Invoice类的责任。它可能需要销售税，运费，客户折扣等。一旦打开这些门并尝试将这些项目带入您的Invoice实体，它就会成为一切类。域服务更适合于实体的协调和为它们提供服务。基础设施服务更适合持久性和外部通信等。这两个都可以通过IoC注入其他服务（并鼓励他们自己不要成为英国媒体报道）。

Answer 3

我也反对它，但建议阅读DDD forum，因为那里有很多关于它的帖子。你是否应该注入领域服务，我认为不是更复杂的领域，这是值得怀疑的。

正如Bil所说，服务非常适合跨集合协调，特别是与域外任何事情的任何协调。

Answer 4

我一般建议不要这样做。

当您的实体获得履行职责所需的事项时，它通常会使您的域名更加清洁。当他们不得不重新审视时，他们通常会采取快捷方式，通过对域和域成员之间的关系进行更多分析来避免可以避免的捷径。

在我看来，应用程序和域服务通常是允许注入的更好的地方。他们还可以负责创建/持久化实体。

Answer 5

绝对。这就是你不把这个类绑定到某个特定的持久性实现的方法。有时候我会编写模拟DAO类，它们只能“持久化”到内存结构中，并在单元测试时注入这些类。