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

解决方案

这就是电子表格难题：我们是在写repository.store(entity)还是entity.storeIn(repository)？

每个都有其优点。通常，我倾向于倾向于repository.store(entity)，其主要原因是我将实体的方法放在领域中。编写pen.dispenseInkOnto(Surface)很有意义，因为那是钢笔所做的。编写pen.storeIn(penRepository)有点没意义。

缺点是我们需要向持久性类提供对实体类内部的访问。除了会引入与entity.storeIn()相同问题的getter之外，我还会使用一个朋友类，受包保护的访问，内部访问或者某种类型的朋友类模式来将内部访问限制为仅需要它。

至于一般的类注入，在pen.dispenseInkOnto(Surface)示例中，我们可以很好地将Surface设置为接口并使用注入。只要我们注入其他实体，值对象或者服务，我就认为这没有问题。

绝对地。这就是我们不将类绑定到某些特定的持久性实现的方式。有时，我编写模拟的DAO类，仅"持久化"到内存结构，并在单元测试时注入它们。

我通常会建议不要这样做。

当为实体提供执行职责所需要做的事情时，通常可以使域保持清洁。当他们必须查找事物时，他们通常会采用快捷方式，通过对域和域成员之间的关系进行更多分析可以避免这些快捷方式。

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

通常我建议不要这样做。实体仅此而已，它们应该代表核心领域中一些可识别且重要的部分。他们应该承担一项责任，并且非常非常善于做到这一点。如果实体需要其他服务才能完成任务(例如坚持下去)，那么我们就开始让基础架构之类的东西进入域。即使发票概念能够计算其账单价值，也不一定是发票类的责任。它可能需要诸如营业税，运输成本，客户折扣之类的东西。一旦打开这些门并尝试开始将这些项目带入Invoice实体，它便成为了一切类。域服务更适合于实体的协调并为其提供服务。基础结构服务更适合持久性和外部通信之类的事情。两者都很好，可以通过IoC注入其他服务(并受到鼓励，因此它们本身不会成为过时的软件)。

我也建议不要这样做，但建议我们阅读DDD论坛，因为那里有很多关于它的帖子。我认为是否应该在更复杂的域中甚至加入域服务还是个问题。

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