Существуют ли зависимости от зависимостей от внедрения?

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

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

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

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

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

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

13 голосов | спросил cgTag 15 J0000006Europe/Moscow 2014, 19:09:41

3 ответа


8

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

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

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

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

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

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

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

ответил Doc Brown 16 J0000006Europe/Moscow 2014, 00:55:25
19

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

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

ответил Robert Harvey 16 J0000006Europe/Moscow 2014, 00:40:32
0

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

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

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

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

ответил maaartinus 16 J0000006Europe/Moscow 2014, 01:01:11

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132