5

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

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

4

6 回答 6

4

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

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

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

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

于 2009-09-13T01:15:18.173 回答
3

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

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

于 2009-09-13T00:28:34.167 回答
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>();

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

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

于 2009-09-13T06:06:44.800 回答
1

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

于 2009-09-13T00:28:57.943 回答
1

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

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

于 2009-09-13T01:32:15.197 回答
-1

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

=)

于 2009-10-28T01:17:37.707 回答