使用依赖注入的开销
依赖注入是否会导致巨大的开销？
我想是这样，特别是如果解析器被多次调用（这很可能是在查看模式示例）？还是我想错了？不幸的是，我无法亲自测试，因为我从未使用过它，但计划使用它。
Does dependency injection potentially cause large overhead?
I would imagine so, especially if the resolver is called many times (which is quite likely looking at pattern examples)? Or am I thinking wrong? Unfortunately I can't test for myself as I have never used it but planned on using it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
除非您使用服务定位器，否则我怀疑开销会产生显着差异。 （即使是，它也不太可能很重要。）
使用构造函数注入和现代框架，解析器将在构造对象时被调用。在大多数情况下，我怀疑您会发现具有依赖项的对象是相对高级的组件、寿命较长或两者兼而有之。
如果您使用 IoC 容器并在紧密循环中创建大量具有依赖关系的对象，您可能需要进行一些优化。您始终可以对其进行分析或基准测试。
简而言之，我不会担心。
Unless you're using a service locator, I doubt that the overhead will make a significant difference. (Even if you are, it's unlikely to be significant.)
Using constructor injection and a modern framework, the resolver will get called when objects are constructed. For the most part I suspect you'll find that the objects with dependencies are relatively high-level components, long-lived, or both.
If you're using an IoC container and creating a lot of objects with dependencies in a tight loop, you might need to do some optimization. You could always profile or benchmark it.
In short, I wouldn't worry about it.
依赖注入作为一个概念不需要有很高的开销：它只是构造一个类，以便可以在运行时构造它与其他类的连接，而不是在代码中硬连接。
当然，有多种方法可以构建可能具有较高开销的运行时连接。避免这些方式。
Dependency injection as a concept need not have high overhead: it's simply structuring a class so that its connections to other classes can be constructed at run time rather than being hard-wired in the code.
Of course, there are ways to build that run-time connection that might have high overhead. Avoid those ways.
http://www.codinginstinct.com/2008/ 04/ioc-container-benchmark-unity-windsor.html 用于一些性能测试。每个测试运行 1000000 个创作。
请注意，基准测试显示了单例分辨率和瞬态分辨率：单例是指您注册类的实例，例如（使用 Unity）：
并且每次都会返回该实例（速度相当快）。
瞬态是您仅注册类类型的地方，IoC 框架将为您完成创建它的工作，例如（在 Unity 中）
这比返回单例需要更多时间。
就整体优化而言，依赖注入的开销很小；其他性能瓶颈更有可能是需要优化的事情。
http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html for some performance testing. Each test was running 1000000 creations.
Note that the benchmark shows singleton resolution and transient resolution: a singleton is there you register an instance of a class e.g. (using Unity):
and this instance is returned every time (which is quite quick).
A transient is where you register just the class type and the IoC framework will do the job of creatnig it for you e.g. (in Unity)
This takes more time that returning a singleton.
In terms of overall optimisation, the overhead of the dependency injection is small beer; other performance bottlenecks are more likely to be the things to optimise.
依赖注入本身只是一个简单的间接，因此存在开销，但确实很小。运行时模式匹配和解析是另一回事（但虽然经常与依赖注入一起使用，但 DI 并不需要这样的额外功能；-）。
Dependency Injection per se is just a simple indirection, so there's overhead but it's pretty minor indeed. Runtime pattern matching and resolving is another thing (but while often used with Dependency Injection, it's not as if DI demands such extras;-).
依赖注入不会带来巨大的开销。我确信您会在其他地方找到瓶颈。如果您非常担心开销，可能 C# 不是您想要使用的语言。您使用 C# 是为了它带来的好处，它抽象了一些您不想处理的细节。
与 DI 相同，它也有一些好处，例如使您的应用程序松散耦合，这意味着您将来会更容易维护它。
Dependency injection is not going to give huge overhead. I'm sure you'll find bottleneck somewhere else. If you are concerned so much about overhead may be C# is not the language you want to use. You use C# for benefits it's brings, it abstracts some details you don't want to deal with.
The same with DI, it also has benefits like making your application loosely coupled and that means that it will be easier for you maintain it in the future.
开销与可测试和可维护的代码...我选择可测试和可维护的代码（你总是可以购买更快的计算机）
=）
Overhead vs testeable and maintainable code ... I choose testeable and maintainable code (you can always buy a faster computer)
=)