使用依赖注入的开销

除非你用的是 service locator 我怀疑开销会有很大的不同。(即使你是,也不太可能有意义。)

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

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

简而言之,我不会担心的。

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

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

依赖注入 本身 只是一个简单的间接操作,所以有开销,但实际上很小。运行时模式匹配和解析是另一回事(但通常与依赖注入一起使用,但它不像DI那样 需求量 这样的额外部分;

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

与DI一样,它也有一些好处,比如使您的应用程序松散耦合,这意味着您将来更容易维护它。

http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html 用于某些性能测试。每个测试运行1000000个创建。

注意,基准测试显示了单例解析和瞬时解析:单例是指注册类的实例,例如(使用Unity):

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

每次都会返回这个实例(这很快)。

暂时的情况是你只注册类类型,而IOC框架将为你完成创建它的工作,例如(在Unity中)

container.RegisterType<IMyType, ConcreteMyType>();

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

在总体优化方面,依赖注入的开销很小;其他性能瓶颈更可能是需要优化的东西。

开销与可测试和可维护的代码…我选择可测试和可维护的代码(你总是可以买一台更快的计算机)

=)