依赖注入导致工厂激增？

发布于 2024-11-09 13:19:06 字数 451 浏览 0 评论 0原文

自从我一直使用依赖注入原理以来，在处理需要实例化大量对象的类时，我总是感到不舒服。

例如，假设我有一个类应该引发许多不同类型的事件。每个事件都有不同的类型，所以我要做的就是为每个不同的事件类型建立一个不同的工厂。如果我有 10 个活动，那么我就必须有 10 个工厂。这看起来不太好。我也可以拥有一个工厂来处理所有不同类型的事件，但这似乎也不太正确。

（对于 C# 人群，我在这里不是在谈论 .NET 的事件。这只是一个切入主题的示例，只需将它们视为常规类即可！）

这只是一个示例。我在这里或那里拥有一个工厂没有问题，但在某些类型的项目中，必须在运行时创建大量对象，似乎我必须为我定义的几乎每个类创建一个工厂！

你如何处理这种情况？我错过了什么吗？

我见过人们只是传递对他们使用的 IoC 容器的引用，但这对我来说似乎没有任何好处。 IMO，域模型甚至不应该知道正在使用 IoC 容器！

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

流云如水 2024-11-16 13:19:06

自从我了解 DI 以来，我就一直是构造函数注入的粉丝，因为在我看来，这就是构造函数的用途。它指出“我需要以下类/接口的实例才能完成我的工作” - 例如，传递给我一个 File 和一个 PrintWriter，我将编写以下内容前者对后者。

当然，这意味着代码不知道 DI 框架，因为该类只是使用传入的所需依赖项进行构造。此外，我认为在这种情况下不需要工厂，因为该类通过构造函数是它自己的工厂。

至于您在第二段中确定的场景，我不确定这是否与依赖注入严格相关，而只是与类层次结构和职责的设计相关。或者你的类具体知道如何创建一个Event来对应例如登录失败，在这种情况下它会这样做（即通过调用类的构造函数）；或者，它不知道如何做，在这种情况下，它必须委托给某种类型的工厂来创建事件。

在这种情况下，您可以将您的类设置为使用同一个工厂来创建所有十个事件（定义具有 10 个方法的 EventFactory 接口），或者您可以定义一个单独的工厂接口（和实现）对于需要构建的每种类型的事件。在后一种情况下，您还需要在主类的构造函数中传递十个不同的工厂。

但再说一遍 - 这与 DI 恕我直言没有任何关系，这是一个如何设计类以实现灵活性（或“企业性”）与直接性的问题。在我看来，这两者是正交的；您首先定义您的类需要哪些协作者（十个工厂、一个工厂或零个工厂），然后使用 DI 来提供这些依赖项。 DI 的存在与否不应影响您的类设计。

回复收藏 0 原文

东风软 2024-11-16 13:19:06

一个类实例化许多其他对象并没有什么问题。相反，该类应被视为聚合根域实体。对于不同“类型”的实体，如果假设它们实现相同的接口或继承自相同的基类，则将 type 参数传递给 Factory.create(type) 这是我通常处理这个问题的方式。 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 的引用，因此 FactoryA 注入了对 FactoryB 的引用，该引用在 create()方法。

There's nothing wrong with a class that instantiates many other objects. Instead, that class should be treated as an aggregate root domain entity. As for different "types" of entity, if you assume they implement the same interface or inherit from the same base class, then passing a type argument to Factory.create(type) is how I usually go about approaching this issue. The internals of create() may delegate to other classes ala the Strategy pattern, but the client facing API is straightforward.

Now if you're creating a factory for every class you're dealing with, that sounds like something of anti-pattern. Study the aggregate root pattern mentioned above and see if you can organize your entities into graphs - you should be able to - such that one factory suffices for generating the whole graph.

As for IoC, the domain model should not know about the container. When I have entities that need references to singletons - usually factories - in the container I usually inject one factory into another as such:

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 {}

So in the above example both FactoryA and FactoryB are singletons managed by the IoC container. EntityA needs a reference to FactoryB, so FactoryA is injected with a reference to FactoryB that's passed along inside the create() method.

回复收藏 0 原文

~没有更多了~