依赖注入是否可能会导致大量开销？
我想是这样，特别是如果多次调用解析器（这很可能是查看模式示例）？还是我想错了？不幸的是，我无法自己测试，因为我从未使用过它，但计划使用它。
1814 次
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 回答