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

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

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

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

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

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

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

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

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

• выберите фреймворк у поставщика, в которого вы верите, что он может предоставлять вам обновления и новые выпуски в течение нескольких лет

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

• написать свой собственный фреймворк

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

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

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

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

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

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

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

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