有状态对象（非全局）的 IoC 依赖注入答案

【问题标题】：IoC Dependency Injection for stateful objects (not global)有状态对象（非全局）的 IoC 依赖注入
【发布时间】：2011-06-08 06:27:21
【问题描述】：

我是这个 IoC 和 DI 业务的新手——如果你传递的是全局范围的对象，我觉得我明白了这个概念，但是当你需要传递一个对象时，我不明白它是如何工作的具有特定逻辑状态的对象。因此，例如，如果我想将一个人对象注入到一个写文件命令对象中——我如何能够动态地选择正确的人对象？从我所见，我可以默认构造对象，但我的断开是你不会使用默认的人对象，它需要是动态的。我假设 IoC 容器可能只是在传递对象时为您维护对象的状态，但是假设您只处理一个人对象，因为没有线程安全，对吗？我知道我遗漏了一些东西（可能是工厂类之类的东西），但我需要更多关于它如何工作的信息。

【问题讨论】：

标签： dependency-injection ioc-container

【解决方案1】：

好吧，您始终可以将Abstract Factory 注入您的消费者并使用它来创建本地范围的对象。

这有时是必要的。请参阅以下示例：

但是，一般来说，我们倾向于不将 DI 用于实体，而主要用于服务。相反，实体通常是通过某种存储库创建的。

【讨论】：

那么一般来说，实体根本不会成为 DI 基础架构的一部分？我是不是把事情复杂化了？
没错：实体和价值对象往往过着不同的生活。从某种意义上说，它们仍然以某种方式由 DI 基础设施管理（理想情况下，一切都是），但是以一种非常间接的方式。它们通常通过存储库等被读取和写入永久存储，那些是作为 DI 基础架构一部分的服务。
好吧，我以为 DI 负责人说应该从 IoC 容器（通过配置）中提供 person Enitity 对象...
...虽然这可以通过 FactoryClass 从数据库（客户端/服务器架构）动态创建实体，但这不是必需的，可以单独管理。我正在收集的是 A）人员对象实体不需要成为 DI 基础设施/配置的一部分，只有服务通常以这种方式注入，B）如果人员对象本身需要，我可以将其添加到 DI 基础设施/配置中服务对象在构建时，我会使用 FactoryClass 从数据库中创建人员实体的动态实例。
可以这样想：有一组已知的服务，这意味着您可以配置一个 DI 容器来包含它们。但是，当涉及到实体和值对象时，它们的数量将是未知的。因此，它们不是基础架构的一部分，因为它们是您的应用程序操作的数据。

【解决方案2】：

当您构造一个服务对象（例如WriteFileService）时，您会向其中注入它在内部完成工作所需的东西。也许它需要一个文件系统对象或其他东西。

您示例中的Person 对象应作为方法调用的参数传递给服务对象。例如writeFileService.write(person)

【讨论】：

所以您不会将 WriteFileService 注入到实体人员对象中......所以在这种情况下，我可以看到如何在没有 DI 基础架构的情况下使用实体。虽然，WriteFileService 在创建时可能使用了 DI 基础架构（基于对写入特定输出的注入类的需要，例如 WriterA - 写入数据库，WriterB - 对控制台的权限等......）。