Накладные расходы от использования Dependency Injection

Question

Может ли внедрение зависимостей вызвать большие накладные расходы?

Я так себе представляю, особенно если распознаватель вызывается много раз (что весьма вероятно при просмотре примеров)? Или я не так думаю? К сожалению, я не могу проверить себя, так как никогда не использовал его, но планировал его использовать.

Answer 1

Если вы не используете сервисный локатор , я сомневаюсь, что накладные расходы будут иметь существенное значение. (Даже если это так, вряд ли это будет значительным.)

Используя внедрение конструктора и современный фреймворк, распознаватель будет вызываться при создании объектов. Я подозреваю, что по большей части вы обнаружите, что объекты с зависимостями являются компонентами относительно высокого уровня, долгоживущими или обоими.

Если вы используете контейнер IoC и создаете много объектов с зависимостями в узком цикле, вам может понадобиться провести некоторую оптимизацию. Вы всегда можете профилировать или тестировать его.

Короче, я бы об этом не беспокоился.

Answer 2

Внедрение зависимостей как концепция не требует больших накладных расходов: она просто структурирует класс, так что его соединения с другими классами могут создаваться во время выполнения, а не жестко привязаны к коду.

Конечно, есть способы построить это соединение во время выполнения, которое может иметь большие накладные расходы. Избегайте этих способов.

Answer 3

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

Это займет больше времени, чем возвращение синглтона.

С точки зрения общей оптимизации накладные расходы на внедрение зависимости - мелкое пиво; другие узкие места, связанные с производительностью, с большей вероятностью могут быть оптимизированы.

Answer 4

Внедрение зависимостей не приведет к огромным накладным расходам. Я уверен, что вы найдете узкое место где-то еще. Если вас так беспокоит накладные расходы, возможно, C # - это не тот язык, который вы хотите использовать. Вы используете C # для преимуществ, которые он приносит, он абстрагирует некоторые детали, с которыми вы не хотите иметь дело.

То же самое с DI, но также имеет такие преимущества, как слабое связывание вашего приложения, и это означает, что вам будет проще поддерживать его в будущем.

Answer 5

Внедрение зависимостей само по себе - это просто косвенное указание, так что есть накладные расходы, но на самом деле они довольно незначительны. Сопоставление и разрешение паттернов во время выполнения - это еще одна вещь (но, хотя часто используется с Dependency Injection, это не так, как если бы DI требовал таких дополнений; -).

Answer 6

накладные расходы по сравнению с проверяемым и поддерживаемым кодом ... Я выбираю проверяемый и обслуживаемый код (вы всегда можете купить более быстрый компьютер)

=)