DI的使用模式/用例或何时开始使用它

Question

我不确定哪个用例应该在应用程序中使用DI。我知道注入PlaceService或CalculationService等服务非常合适，但我是否应该像DI User一样用DI创建我的域对象？如果User只有一个构造函数需要名字和姓氏，那该怎么办？ DI可解决这个问题吗？

我应该使用DI来创建Set / List接口的实例还是纯粹的过度杀伤？

我主要使用guice。

Answer 1

ig0774的答案是一个很好的起点。另外，我想提供这样的经验法则：

在Domain-Driven Design的术语中，您应该使用服务的DI，而不应该实体或值对象。

换句话说，DI符合概念上长寿命的无状态对象，其中通常使用一个或已知的数字。

Answer 2

我使用的规则通常是支持依赖注入，除非可以使用纯粹的原始值构造对象，并且没有/很少有机会将对象替换为另一个实现。

但是，对于域对象，特别是如果您的对象不构成anemic domain model，即对象只是getter和setter的包，那么拥有对象可能会很有用，例如，它们可以自行保留对于那些类型的对象，依赖注入和Salve可以是一个强大的组合。

Guice有一个特定的解决方案，可以解决像User对象这样的对象所引起的问题类型AssistedInject，尽管其他轻量级容器也可以使用类似的东西，或者使用构建器或适配器模式。