依赖注入导致工厂激增？

如何解决依赖注入导致工厂激增？

| 由于我一直在使用“依赖注入”原理，因此在处理需要实例化许多对象的类时，我总是感到不舒服。 例如，假设我有一个应该引发许多不同类型事件的类。每个事件都有不同的类型，所以我要做的是为每个不同的事件类型使用不同的工厂。如果我有10个事件，那么我将必须有10个工厂。看起来不太好。我也可以为所有不同类型的事件建立一个工厂，但这似乎也不是很正确。 （对于C＃人群，我在这里不是在谈论.NET \的事件。这只是一个例子，可以将它们视为常规类！） 这只是一个例子。我在这里或那里建立工厂没有问题，但是在某些必须在运行时创建大量对象的项目中，似乎我必须为我定义的几乎每个类都建立工厂！ 您如何处理这种情况？我想念什么吗？ 我见过人们只是绕过他们使用的IoC容器的引用，但这对我来说似乎没有任何好处。 IMO，域模型甚至都不应该知道正在使用IoC容器！ 谢谢     

解决方法

实例化许多其他对象的类没有错。相反，该类应被视为聚合的根域实体。对于不同的“类型”实体，如果您假定它们实现相同的接口或从相同的基类继承，那么通常将“ 0”参数传递给“ 1”是我通常要解决的问题。

create()

的内部结构可以将策略模式委托给其他类，但是面向API的客户端很简单。 现在，如果您要为要处理的每个类创建一个工厂，这听起来像是一种反模式。研究上面提到的聚合根模式，看看您是否可以将实体组织成图-您应该能够-这样一个工厂就足以生成整个图。 对于IoC，域模型不应了解容器。当我在容器中有需要引用单例的实体时（通常是工厂），我通常将一个工厂注入另一个工厂中，例如：

class FactoryA {
    void setFactoryB(FactoryB factoryB) { /* sets into state */ }
    EntityA create(Enum type) {
        EntityA entityA = new EntityA();
        /* DI FactoryB - this method is probably default access */
        entityA.setFactoryB(getFactoryB());
    }
}

class FactoryB {}

因此，在上面的示例中，

FactoryA

和

FactoryB

都是由IoC容器管理的单例。 EntityA需要对

FactoryB

的引用，因此ѭ4with被注入对

create()

方法内部传递的

FactoryB

的引用。     ,自从了解DI以来，我就一直喜欢构造函数注入，因为在我看来，这就是构造函数的用途。声明“为了完成我的工作，我需要以下类/接口的实例”-例如递给我10英镑和11英镑，我将前者的内容写给后者。 当然，这意味着代码不了解DI框架，因为该类只是通过传递其所需的依赖项来构造的。此外，在这种情况下，我认为工厂没有必要，因为该类是通过构造函数自己的工厂。 至于您在第二段中确定的方案，我不确定这是否与依赖项注入严格相关，而只是确定类层次结构和职责的设计。您的班级中的每个人都特别知道如何创建与例如登录失败，在这种情况下会这样做（即调用类的构造函数）;或者，它不知道如何操作，在这种情况下，它将不得不委托某种工厂来创建

Event

。 在这种情况下，您可以将您的类设置为使用同一工厂来创建所有十个事件（使用10种方法定义

EventFactory

接口），也可以为每种需要构造的事件类型定义单独的工厂接口（和实现） 。在后一种情况下，您还需要在主类的构造函数中传递十个不同的工厂。 但是，再次，这与DI IMHO无关，这是一个关于如何设计类以实现灵活性（或“企业性”）与简单性的问题。在我看来，两者是正交的。您首先定义您的班级需要哪些协作者（十个工厂，一个工厂或零个工厂），然后使用DI提供那些依赖关系。 DI的存在与否不会影响您的课堂设计。