Представляют ли структуры внедрения зависимости риск зависимости?

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

Через некоторое время я заметил, что большое количество внутренних библиотек стало зависимым от используемой мной структуры DI. В результате весь проект теперь зависит от этой сторонней структуры.

Я видел иронию в том, чтобы отделить все зависимости, сделав их зависимыми от общей библиотеки.

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

Меня беспокоит то, что используемая мной структура DI устарела или нуждается в замене.

Существует ли шаблон разработки при работе с DI, который уменьшает связь между проектом и структурой DI?

frameworks dependency-injection

— Reactgular
источник

Шаблон «не используйте DI-фреймворк». Хотя я должен задаться вопросом, решаете ли вы проблему, которой у вас на самом деле нет - насколько вероятно, что вы измените структуру DI?

— Одед

@ Хорошая структура DI должна иметь возможность прозрачно работать с кодом, но в некоторых случаях это невозможно. Затем вы должны использовать DI API внутри ваших классов. В этих случаях сложно совместно использовать или изменять структуру DI без необходимости изменения этих классов. Так как я впервые работаю с этой структурой DI. Я не уверен, что мне нужно будет заменить его.

— Reactgular

Ваша система также зависит от электричества. Я предлагаю вам сначала отделить это.

— Идан Арье

@ MathewFoscarini Разве это не анти-паттерн? Вы можете сделать это, но не должны, поскольку это запутывает зависимость.

— Мааартин

@MathewFoscarini на DIFramework.Get<IService>()самом деле не является инъекцией зависимости; это связанный шаблон под названием Service Locator. Многим людям не нравится Service Locator, потому что он связывает вас с платформой и потому, что им слишком легко злоупотреблять (например, Singleton). У Мартина Фаулера есть потрясающая статья об этих шаблонах: martinfowler.com/articles/injection.html

— Бенджамин Ходжсон,

Ответы:

Вы полностью правы - использование инфраструктуры DI, скорее всего, сделает ваш код зависимым от этой вещи. На самом деле, это слишком удивительно, поскольку это, как правило, верно для любой другой фреймворка или базовой библиотеки, особенно когда эта библиотека поддерживает ваш проект с некоторыми универсальными функциями, используемыми везде в вашем коде. Например, когда вы решите использовать определенную среду пользовательского интерфейса или веб-среду, впоследствии это решение будет сложно изменить, как только вы создадите определенный объем кода на основе этой библиотеки. Когда вы решите использовать определенный (возможно, нестандартный) Stringкласс, вы не сможете легко изменить это решение позже. Такое решение является архитектурным, оно похоже на выбор определенного языка программирования и попытка изменить это решение после того, как вы написали> 100К строк кода.

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

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

Идея создания библиотеки-обертки заранее не нова, но я редко видел, как это работает, поскольку вам придется делать предположения для будущей ситуации, для которой вы не знаете, ударит ли она или когда она вас ударит, и что «новая» структура будет выглядеть так. С другой стороны, несколько лет назад мы успешно заменили полную инфраструктуру пользовательского интерфейса в проекте C ++ с ~ 120 КБ строк кода, применяя стратегию адаптера, которую я упоминал выше.

— Док Браун
источник

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

Контейнеры DI представляют собой шаблон «корпоративного программного обеспечения», используемый, когда граф объектов очень большой и сложный. Я подозреваю, что 95% приложений не требуют этого.

— Роберт Харви
источник

Я согласен, что небольшие проекты не требуют этого, но 95 +% проектов могут извлечь из этого выгоду .

— Маартин

@maaartinus: ненужная сложность для минимальной выгоды.

— Роберт Харви

Что за? Это моя статистика для каждого класса: 0,5 аннотации, 0,1 строки конфигурации. Так какую сложность ты имеешь ввиду ???

— Maaartinus

@RobertHarvey: хотя я полностью согласен с вашими утверждениями выше, ФП заявляет, что он уже ввел структуру DI. Сказать ему «лучше не надо» на самом деле не является ответом на его вопрос.

— Док Браун

@maaartinus, чем больше автоматизируется фреймворк и чем больше вещей он может внедрить, тем сложнее. Существуют XML-файлы конфигурации, внедрение конструкторов, внедрение свойств, автоматическое моделирование объектов, отложенное внедрение и т. Д. И т. Д. И т. Д. Эти инфраструктуры DI могут стать очень сложными.

— Reactgular

Я не думаю, что DI-фреймворки могут действительно устареть в ближайшее время. Что должно случиться, чтобы сделать его устаревшим?

Может быть, изобретение нового и более умного образца? Однако, как бы это ни выглядело, это потребовало бы гораздо больших изменений в коде.
Изменение языка может быть? Еще хуже.

Я бы сказал, что нынешний DI достаточно зрел, и я не знаю, что там происходит. Вы не указали свой язык, так что, говоря о Guice , он довольно ненавязчив и работает со стандартными аннотациями Java (также использует их для вещей, которые не стандартизированы, но вам это редко требуется). Он с открытым исходным кодом, широко используется и лицензирован Apache. В чем может быть проблема?

Я почти уверен, что изменение структуры DI будет на порядок проще, чем изменение любой другой библиотеки (например, изменение пользовательского интерфейса означает гораздо больше работы).

— maaartinus
источник