Действительно ли платформы внедрения зависимости стоят дополнительного косвенного слоя?

Преимущества DI являются трудными хвататься за первый взгляд. Тестируемость является самой очевидной. Я попытаюсь выдумать очень короткий пример для иллюстрирования этих преимуществ. Предположите, что Ваше приложение использует определенного поставщика БД. Если Вы сохраняете весь свой код, видят только интерфейс поставщика БД, Вы легко переключитесь от одной реализации до другого. Теперь, если Вы делаете корпоративные приложения, не в зависимости от конкретного поставщика БД может быть чрезвычайно желательным, как то, когда клиент уже купил лицензию DB. Это - на самом деле преимущество в зависимости от интерфейса и не реализации.Пока все хорошо. Теперь, я должен так или иначе овладеть своим конкретным объектом. Мой конкретный объект может быть экземпляром конкретного поставщика только. Как я делаю это?

1. Используйте новый для создания объекта.
   Я должен буду перекомпилировать проект для распределения его. Огромная оборотная сторона: должен будет протестировать, развернуть, поддержать новое ответвление кода и т.д.
2. Используйте фабрику.
   Мой код будет опрыснут кодом, который овладевает фабрикой и получает экземпляр. Кроме того, я должен буду возвратить универсальный экземпляр и бросить его к типу объекта, который я ожидаю. В противном случае я должен буду изменить интерфейс Factory каждый раз, когда я добавляю новый объект, созданный фабрикой.
3. Используйте сервисный локатор.
   Подобный как 2. Только, в зависимости от Сервиса Локатор не мог бы всегда быть вокруг, как Java JNDI.

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

Для нетривиальных "enterprisey" приложений да это стоит того. Перед платформами DI каждый магазин реализовал свой собственный необычный класс "ServiceLocator" в некоторой внутренней библиотеке, которой пользовались их другие проекты. Таким образом, у Вас были вызовы к той вещи, замусоренной всюду по кодовой базе.

Те вызовы представили потребность объектов обнаружить/настроить их собственные зависимости. Платформа DI устраняет весь этот код, таким образом, Ваши объекты становятся более простыми и поэтому, легче протестировать.

Теперь, из этого следует, что, если у Вас нет большого количества изменчивости в зависимостях Ваших объектов, значение косвенности (централизованная конфигурация) меньше для Вас.

Для получения дополнительной информации контрастирующий DI к ServiceLocator, посмотрите Инверсию Fowler Контейнеров Управления и шаблона Внедрения зависимости

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

Для платформы DI

Против платформы DI

Нижняя строка сводится, делает это, действительно уменьшают сцепление связи и увеличения, или делает это, просто продвигают проблемы под поверхностью. На моем проекте прямо сейчас я не вижу много потребности в нем, даже для поддержки поблочного тестирования. Если бы Вы собирались взять один для C#, хотя, я настоятельно рекомендовал бы Ninject. Это легко, просто и полностью бегло настроенное... никакой XML! Sweeet :)

Я нашел, что пользовательская статическая фабрика HashTable отделяет мои прекрасные зависимости и удовлетворяет мои потребности. Я попытался несколько раз использовать полный удар контейнер МОК и каждый раз, когда я озадачен кривой обучения (и вся конфигурация), что остальная часть моей команды должна выносить... и все это для минимальных дополнительных функций по моей ванили.

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

Мы склонны брать большую пушку москиту, потому что оружие выглядит прохладным.

P

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

Если навигация через исходный код является слишком трудной, получите Resharper, и все прекрасно.

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

Однако Инверсия Управления не является единственным способом пойти сюда. Коллега достиг этого через запись его собственной реализации JNDI. Потребовалось долгое время для завоевания меня вокруг, но это фантастически и имеет часть конфигурации типичного проекта Spring.

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

Я для каждый знает, что каждый раз, когда я попытался использовать платформу DI, это - по существу все, для чего я действительно закончил тем, что использовал ее. Я также видел случаи, где люди переносят свой контейнер DI в статический класс МОК для создания объектов путь вниз в иерархии, и в моем уме этот вид поражений цель; разве это не просто назад к тому, чтобы быть сервисным локатором в той точке? Я предполагаю, что не вполне получаю различие в практическом использовании. Я говорю, что интриги, Вы используете отражение и получаете большой удар запуска, чтобы сделать то же самое.

Вы не можете устранить зависимости, но уверенный можно запутать heck из них в конфигурационном XML-файле. В какой-то момент что-то собирается звонить new. Вы действительно собираетесь выгрузить реализацию интерфейса, не перекомпилировав или повторно тестируя Ваше приложение так или иначе? В противном случае сохраните это простым. Хорошо нажать "Find Definition" и видеть что-то на самом деле инстанцируемое в сервисном классе локатора с явным одиночным элементом или ThreadStatic или некоторое другое поведение.

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

Я думаю, что преимущество зависит от того, как Вы используете его.

Например, на моем текущем проекте, мы используем DEP inj для введения различных объектов в зависимости от конфигурации приложения, специфически поблочного тестирования. Хороший пример имел бы производственное системное использование реальная реализация "входа в систему", но имел бы использование модульных тестов ложный "вход в систему", который всегда возвращает true для, знает вход в систему, но никаких других.