使用依赖注入的开销

题

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

我会这么想，尤其是如果多次调用旋转变压器（很可能会看到模式示例）？还是我错了？不幸的是，我无法测试自己，因为我从未使用它，但计划使用它。

解决方案

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

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

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

简而言之，我不担心。

其他提示

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

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

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

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

并且每次都返回此实例（这很快）。

瞬态是您只注册类类型的地方，IoC框架将为您创建它，例如：（在Unity中）

container.RegisterType<IMyType, ConcreteMyType>();

返回单身人士需要更多时间。

就整体优化而言，依赖注入的开销是小啤酒;其他性能瓶颈更可能是要优化的事情。

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

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

与DI相同，它还具有使应用程序松散耦合等优点，这意味着将来更容易维护它。

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

=）

许可以下： CC-BY-SA 和归因