Накладные расходы от использования внедрения зависимостей
-
06-07-2019 - |
Вопрос
Может ли внедрение зависимостей привести к большим накладным расходам?
Я бы так себе представлял, особенно если преобразователь вызывается много раз (что, вполне вероятно, связано с примерами шаблонов)?Или я неправильно думаю?К сожалению, я не могу проверить это на себе, так как никогда не использовал его, но планировал использовать.
Решение
Если вы не используете локатор служб , я сомневаюсь, что эти издержки сделать значительную разницу. (Даже если это так, вряд ли это будет важно.)
Используя внедрение конструктора и современный фреймворк, распознаватель будет вызываться при создании объектов. Я подозреваю, что по большей части вы обнаружите, что объекты с зависимостями являются компонентами относительно высокого уровня, долговечными или обоими.
Если вы используете контейнер IoC и создаете много объектов с зависимостями в тесном цикле, вам может потребоваться выполнить некоторую оптимизацию. Вы всегда можете профилировать или тестировать его.
Короче, я бы об этом не беспокоился.
Другие советы
Внедрение зависимостей как концепции не требует больших накладных расходов: оно просто структурирует класс, так что его соединения с другими классами могут создаваться во время выполнения, а не жестко встраиваться в код.
Конечно, есть способы создания этого соединения во время выполнения, которое может иметь большие накладные расходы. Избегайте этих способов.
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>();
Это займет больше времени, чем возврат одиночного.
С точки зрения общей оптимизации накладные расходы на внедрение зависимостей - мелкое пиво; другие узкие места в производительности, скорее всего, будут оптимизировать.
Внедрение зависимостей как таковое - это просто косвенное указание, поэтому есть издержки, но на самом деле они довольно незначительны. Сопоставление и разрешение паттернов во время выполнения - это еще одна вещь (но часто используется с Dependency Injection, но DI не требует таких дополнений; -).
Внедрение зависимостей не приведет к огромным накладным расходам. Я уверен, что вы найдете узкое место где-то еще. Если вас так беспокоит накладные расходы, возможно, C # - это не тот язык, который вы хотите использовать. Вы используете C # для преимуществ, которые он приносит, он абстрагирует некоторые детали, с которыми вы не хотите иметь дело.
Как и в случае с DI, у него также есть такие преимущества, как слабое связывание вашего приложения, и это означает, что вам будет проще поддерживать его в будущем.
Накладные расходы против тестируемого и поддерживаемого кода...Я выбираю тестируемый и поддерживаемый код (вы всегда можете купить более быстрый компьютер)
=)