自从我一直在使用依赖注入(inject)原则以来，在处理需要实例化大量对象的类时，我总是感到不舒服。
例如，假设我有一个类应该引发许多不同类型的事件。每个事件都有不同的类型，所以我要做的是为每个不同的事件类型设置不同的工厂。如果我有 10 个事件，那么我就必须有 10 个工厂。那似乎不太好。我也可以为所有不同类型的事件建立一个工厂，但这似乎也不太对。
(对于 C# 人群，我在这里不是在谈论 .NET 的事件。这只是一个切入点的示例，只需将它们视为常规类即可!)
这只是一个例子。我在这里或那里有一个工厂没有问题，但在某些类型的项目中，人们必须在运行时创建很多对象，似乎我必须为我定义的几乎每个类创建一个工厂!
您如何处理这种情况？我错过了什么吗？
我看到人们只是传递对他们使用的 IoC 容器的引用，但这对我来说似乎没有任何好处。 IMO，域模型甚至不应该知道正在使用 IoC 容器!
谢谢
最佳答案
自从我了解 DI 以来，我就一直是构造函数注入(inject)的粉丝，因为在我看来，这就是构造函数的用途。它声明“我需要以下类/接口(interface)的实例才能完成我的工作”——例如传给我一个 File 和一个 PrintWriter，我会将前者的内容写入后者。
当然，这意味着代码不知道 DI 框架，因为类只是在构造时传入了所需的依赖项。此外，我认为在这种情况下不需要工厂，因为该类通过构造函数是它自己的工厂。
至于您在第二段中确定的场景，我不确定这是否与依赖注入(inject)严格相关，而只是类层次结构和职责的设计。 Either 你的类(class)知道如何创建一个 Event 对应于例如登录失败，在这种情况下它会这样做(即通过调用类的构造函数)； 或者，它不知道怎么做，在这种情况下，它必须委托(delegate)给一些工厂来创建事件。
在这种情况下，您可以将您的类设置为使用同一个工厂来创建所有十个事件(定义一个具有 10 个方法的 EventFactory 接口(interface))，或者您可以定义一个单独的工厂接口(interface)(&实现)对于需要构建的每种类型的事件。在后一种情况下，您还需要在主类的构造函数中传入十个不同的工厂。
但同样 - 这与 DI 恕我直言无关，这是一个问题，你如何设计你的类以实现灵 active (或“企业性”)与直截了当。在我看来，这两者是正交的；您首先定义您的类需要哪些协作者(十个工厂、一个工厂或零个工厂)，然后您使用 DI 来提供这些依赖项。 DI 的存在与否不应影响您的类(class)设计。
关于c# - 依赖注入(inject)导致工厂激增？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6110043/