logo标签列表

使用依赖注入所带来的开销

c#dependency-injectionoverhead
5

依赖注入会导致大量开销吗？

我认为可能会，特别是如果解析器被多次调用（从模式示例来看这很有可能）？或者我的想法是错误的吗？不幸的是，我无法自己测试，因为我从未使用过它，但计划使用它。

1
你可能需要重新表述问题，如“使用IoC容器是否会导致大量开销”。许多人区分DI作为一般概念（即在运行时而不是编译时指定依赖项）和IoC容器作为一种特定的DI策略。 - Pete Hodgson
6个回答
5

除非您使用服务定位器，否则我怀疑开销会产生显着差异。(即使您使用它，也不太可能显着影响性能。)

使用构造函数注入和现代框架，解析器将在对象构造时被调用。大多数情况下，我认为具有依赖项的对象是相对高级别的组件、长寿命或两者兼备。

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

简而言之，我不会担心这个问题。

4

依赖注入作为一个概念并不需要高开销：它只是将一个类结构化，以便它与其他类的连接可以在运行时构建，而不是在代码中硬编码。

当然，有一些构建运行时连接的方式可能会有很高的开销。请避免使用这些方式。

3

点击此处进行性能测试。每个测试都运行了1000000次创建操作。

请注意，该基准测试显示了单例解析和瞬态解析：单例是您注册类实例的地方，例如（使用Unity）：

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

每次都返回这个实例（非常快）。
瞬态是你仅仅注册类类型，然后IoC框架会为你完成创建工作，例如（在Unity中）。
container.RegisterType<IMyType, ConcreteMyType>();

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

就整体优化而言，依赖注入的开销微不足道；其他性能瓶颈更有可能是需要优化的地方。

1
谢谢提供链接，解决了很多疑惑。 - nightElf91
1

依赖注入本身只是一个简单的间接方法，因此会有一些开销，但确实非常小。运行时模式匹配和解析是另一回事（虽然经常与依赖注入一起使用，但并不是像DI 要求这样的额外内容;-)。

1

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

同样，DI也有好处，比如使你的应用程序松散耦合，这意味着将来更容易维护。

0

过多的开销与可测试性和可维护性代码的比较...我选择可测试和可维护的代码（你总是可以购买更快的计算机）

=)

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接