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

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

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

Answer 5

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

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

Answer 6

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

=)