Когда вы используете инъекцию зависимости?

Основная проблема с внедрением зависимостей заключается в том, что, хотя это и создает видимость слабо связанной архитектуры, на самом деле это не так.

То, что вы действительно делаете, это перемещаете эту связь из времени компиляции во время выполнения, но все же, если классу A нужен некоторый интерфейс B для работы, экземпляр класса, который реализует интерфейс B, все равно должен быть предоставлен.

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

Использование, которое я видел полезным для инверсии шаблона управления:

• Архитектура плагина. Таким образом, сделав правильные точки входа, вы можете определить контракт на обслуживание, которое должно быть предоставлено.
• Архитектура, подобная рабочему процессу. Где можно подключить несколько компонентов, динамически подключая выход одного компонента к входу другого.
• Для каждого клиентского приложения. Допустим, у вас есть различные клиенты, которые платят за набор "features" вашего проекта. С помощью инъекции зависимостей вы можете легко предоставить только основные компоненты и некоторые компоненты "added", которые предоставляют только те функции, которые были оплачены клиентом.
• Перевод. Хотя это обычно не делается для целей перевода, вы можете "inject" различных языковых файлов по мере необходимости приложения. Это включает в себя RTL или LTR пользовательских интерфейсов по мере необходимости.

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

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

Инъекция зависимостей должна использоваться только для частей приложение, которое необходимо изменить динамически без перекомпиляции базовый код

DI следует использовать для изоляции вашего кода от внешних ресурсов (баз данных, веб-сервисов, файлов xml, архитектуры плагинов). Количество времени, которое потребуется для тестирования вашей логики в коде, будет почти запретительным во многих компаниях, если вы тестируете компоненты, которые DEPEND находятся в базе данных.

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

Что вы имеете в виду под "just adding a property to a class?"

Мое эмпирическое правило состоит в том, чтобы сделать класс unit тестируемым. Если ваш класс полагается на детали реализации другого класса, это должно быть рефакторизовано/абстрагировано до такой степени, чтобы классы можно было тестировать изолированно.

EDIT: вы упоминаете в конструкторе множество интерфейсов. Я бы посоветовал вместо этого использовать сеттеры/геттеры. Я нахожу, что это делает вещи гораздо легче поддерживать в долгосрочной перспективе.

Я делаю это только тогда, когда это помогает с разделением забот.

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

Но это еще не все... во всех остальных случаях это просто сделало бы систему излишне сложной

Даже со всеми фактами и процессами в мире.. каждое решение сводится к решению суда-забыл, где я это читал
Я думаю, что это скорее вызов опыта / времени полета. В основном, если вы видите зависимость как объект-кандидат, который может быть заменен в ближайшем будущем, используйте инъекцию зависимостей. Если я вижу 'classA и его зависимости' как один блок для подстановки, то я, вероятно, не буду использовать DI для a's deps.

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

Есть некоторые приложения, которые просто выбрасываются, но если есть сомнения, я бы пошел дальше и создал интерфейсы. После некоторой практики это не такая уж большая обуза.

Еще один вопрос, с которым я борюсь, - где я должен использовать инъекцию зависимостей? Где вы берете свою зависимость от StructureMap? Только в стартовом приложении? Означает ли это, что все реализации должны быть переданы полностью вниз от самого верхнего слоя до самого нижнего слоя?

Я использую замок Windsor/Microkernel,, у меня нет опыта ни с чем другим, но мне это очень нравится.

Что касается того, как вы решаете, что вводить? До сих пор мне хорошо служило следующее эмпирическое правило: если класс настолько прост, что ему не нужны модульные тесты, вы можете смело создавать его экземпляр в классе, иначе вы, вероятно, захотите иметь зависимость через конструктор.

Что касается того, следует ли вам создать интерфейс или просто сделать ваши методы и свойства виртуальными, я думаю, что вы должны пойти по пути интерфейса, если вы либо а) видите, что класс имеет некоторый уровень повторяемости в другом приложении (т. е. регистраторе), либо Б) Если либо из-за количества параметров конструктора, либо из-за значительного количества логики в конструкторе, класс в противном случае трудно подделать.