c# - 使用依赖注入的开销

Question

依赖注入是否可能会导致大量开销？

我想是这样，特别是如果多次调用解析器（这很可能是查看模式示例）？还是我想错了？不幸的是，我无法自己测试，因为我从未使用过它，但计划使用它。

score 4 · Accepted Answer

除非您使用的是服务定位器，否则我怀疑开销是否会产生重大影响。（即使你是，也不太可能很重要。）

使用构造函数注入和现代框架，解析器将在构造对象时被调用。在大多数情况下，我怀疑您会发现具有依赖关系的对象是相对高级的组件、长期存在的或两者兼而有之。

如果您使用 IoC 容器并在紧密循环中创建大量具有依赖关系的对象，则可能需要进行一些优化。您总是可以对其进行分析或基准测试。

简而言之，我不会担心它。

score 3 · Accepted Answer

依赖注入作为一个概念不需要有很高的开销：它只是构造一个类，以便可以在运行时构造它与其他类的连接，而不是在代码中硬连线。

当然，有一些方法可以构建可能具有高开销的运行时连接。避免这些方式。

score 2 · Accepted Answer

请注意，基准测试显示了单例分辨率和瞬态分辨率：一个单例在那里您注册了一个类的实例，例如（使用 Unity）：

container.RegisterInstance<IMyType>(new ConcreteMyType());

并且每次都会返回这个实例（这非常快）。

瞬态是您仅注册类类型的地方，IoC 框架将为您完成创建它的工作，例如（在 Unity 中）

container.RegisterType<IMyType, ConcreteMyType>();

这比返回单例需要更多时间。

在整体优化方面，依赖注入的开销小啤酒；其他性能瓶颈更有可能是需要优化的东西。

score 1 · Accepted Answer

依赖注入本身只是一个简单的间接，所以有开销，但它确实很小。运行时模式匹配和解析是另一回事（但虽然经常与依赖注入一起使用，但 DI 并不需要这样的额外功能；-）。

score 1 · Accepted Answer

依赖注入不会产生巨大的开销。我相信你会在其他地方找到瓶颈。如果您非常担心开销，可能是 C# 不是您想要使用的语言。你使用 C# 是为了它带来的好处，它抽象了一些你不想处理的细节。

与 DI 一样，它还具有使您的应用程序松散耦合等好处，这意味着您将来维护它会更容易。

score -1 · Accepted Answer

开销 vs 可测试和可维护的代码...我选择可测试和可维护的代码（您总是可以购买更快的计算机）

=)

6 回答 6