Внедрение зависимостей только для тестирования или производства?

Question

Используются ли структуры внедрения зависимостей только для тестирования или в рабочем коде?Кажется, как только вы начнете использовать фреймворк типа ninject, вам не захочется все отменять.Кроме того, есть ли снижение производительности при использовании чего-то вроде ninject?

Answer 1

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

Возможные реальные недостатки DI в основном связаны с процессом кодирования, а не с производственной производительностью. Вероятно, стоит упомянуть: при использовании DI вы теряете возможность проходить по коду с помощью «Перейти к определению» - это всегда приводит вас к интерфейсу, который довольно логичен, но все еще непригоден.

Answer 2

Используйте это для всего!Зачем менять это?Падение производительности для качественной среды должно происходить только при запуске.Плюс может быть небольшое наказание, пока виртуальная машина не сможет разместить дополнительные слои.В любом случае вы видите уменьшение ошибок и повышение производительности разработчика.

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

Когда тесты запущены, конфигурация теста просто помечает определенные службы как отключенные.Это означает, что тестовая конфигурация:

1. выводит список отключенных сервисов
2. указывает возвращаемые значения для различных вызовов методов на отключенных сервисных методах.

Преимущества теста:

1. Отсутствие различий в конфигурации между производством и тестированием означает, что нет возможности появления скрытой ошибки, зависящей от конфигурации
2. Сервисы также внедряются в класс Test.
3. Тестовая конфигурация тривиальна (на самом деле нужна только для случаев, когда сервисы отключены)
4. Тестовая конфигурация всегда совпадает с производственной.(проще в обслуживании)
5. Инициализация службы никогда не выполняется вручную и взламывается вместе.

Преимущества производства:

1. Чистый код запуска - нет жестко закодированных зависимостей
2. Круговые зависимости не являются проблемой.
3. Возможность "отключить" локальную копию службы и направить запросы в другой ящик.(Используется для фоновых пакетных задач)

Answer 3

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