Наверху от использования Внедрения зависимости
C более со строгим контролем типов, чем JavaScript и менее со строгим контролем типов, чем Ada.
я сказал бы, что это больше попадает в сторону со строгим контролем типов континуума. но кто-то еще мог бы не согласиться (даже если они неправы).
, Как это для категорического?
6 ответов
Если вы не используете локатор служб , я сомневаюсь, что накладные расходы будут иметь существенное значение. (Даже если да, это вряд ли будет значительным.)
Используя внедрение конструктора и современную структуру, преобразователь будет вызываться при создании объектов. По большей части я подозреваю, что вы обнаружите, что объекты с зависимостями являются относительно высокоуровневыми компонентами, долгоживущими или и тем, и другим.
Если вы ' При использовании контейнера 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>();
Это занимает больше времени, чем возврат синглтона.
С точки зрения общей оптимизации накладные расходы на внедрение зависимостей - мелочь; другие узкие места производительности, скорее всего, нужно будет оптимизировать.
Внедрение зависимостей как потребность концепции не иметь высоких накладных расходов: он просто структурирует класс так, чтобы его соединения с другими классами могли быть созданы во время выполнения, а не жестко закреплены в коде.
Конечно, есть способы построить это соединение во время выполнения, которое могут иметь высокие накладные расходы. Избегайте этих способов.
Внедрение зависимостей само по себе - это просто косвенное обращение, поэтому накладные расходы есть, но они действительно незначительны. Сопоставление и разрешение шаблонов во время выполнения - другое дело (но, хотя оно часто используется с внедрением зависимостей, DI не требует таких дополнительных услуг; -).
Внедрение зависимостей не приведет к огромным накладным расходам. Я уверен, что вы найдете узкое место где-нибудь еще. Если вас так сильно беспокоят накладные расходы, возможно, C # - не тот язык, который вы хотите использовать. Вы используете C # для получения преимуществ, он абстрагирует некоторые детали, с которыми вы не хотите иметь дело.
То же самое с DI, у него также есть преимущества, такие как создание слабосвязанного приложения, а это означает, что вам будет легче поддерживать это в будущем.
Overhead vs testeable and maintainable code ... I choose testeable and maintainable code (you can always buy a faster computer)
=)