使用依赖注入的开销

时间:2009-09-13 00:25:24

标签: c# dependency-injection overhead

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

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

6 个答案:

答案 0 :(得分:4)

除非您使用service locator,否则我怀疑开销会产生重大影响。 (即使你是,也不太可能是重要的。)

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

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

简而言之,我不担心。

答案 1 :(得分:3)

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

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

答案 2 :(得分:2)

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>();

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

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

答案 3 :(得分:1)

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

答案 4 :(得分:1)

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

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

答案 5 :(得分:0)

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

=)