Чи створюють схеми введення залежності залежність від ризику залежності?

Я реконструював існуючу систему, щоб використовувати ін'єкцію залежності, і ця робота пройшла безперебійно.

Через деякий час я помітив, що велика кількість власних бібліотек стала залежною від структури, яку я використовував. Як результат, весь проект зараз залежить від цієї сторонні рамки.

Я бачив іронію в розв’язуванні всіх залежностей, роблячи їх залежними від спільної бібліотеки.

Моєю першою реакцією було створення бібліотеки обгортки навколо структури залежності. Тому я міг би замінити цю рамку за потреби. Оцінивши залучену роботу, я зрозумів, що отриманий API буде подібний до існуючого фреймворку, і тому ускладнює його заміну. Тому я відмовився від ідеї.

Мене хвилює те, що рамка DI, яку я використовую, застаріла або потребує заміни.

Чи існує закономірність розробки при роботі з DI, яка зменшує зв’язок між проектом та рамкою DI?

frameworks dependency-injection

— Реакційний
джерело

Шаблон "не використовувати рамку DI". Хоча я мушу задуматися, чи вирішуєш ти проблему, якої насправді немає - наскільки ймовірно, ти зміниш рамку DI?

— Одід

@Доданий гарний фреймворк DI повинен мати можливість працювати з кодом прозоро, але є випадки, коли це неможливо. Тоді вам потрібно використовувати API API всередині своїх класів. У таких випадках важко ділитися або змінювати рамки DI, не потребуючи змін цих класів. Оскільки я вперше працюю з цією рамкою DI. Я не впевнений, чи потрібно мені її замінити.

— Реагуючий

Ваша система також залежить від електроенергії. Я пропоную вам спочатку розв’язати це.

— Ідан Ар'є

@MathewFoscarini Це не анти-модель? Ви можете це зробити, але не слід, оскільки це применшує залежність.

— maaartinus

@MathewFoscarini DIFramework.Get<IService>()насправді не є ін'єкцією залежності; це пов'язаний зразок під назвою "Локатор послуг". Багато людей не люблять Локатор послуг через те, що він з'єднує вас з рамками та тому, що надто легко зловживати (наприклад, Singleton). У Мартіна Фаулера є надзвичайна стаття про ці зразки: martinfowler.com/articles/injection.html

— Бенджамін Ходжсон

Відповіді:

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

Якщо весь ваш код залежить від певного фреймворку, це не може бути проблемою, якщо він робить те, що ви від нього очікуєте, і доки він належним чином підтримується. Але це може стати проблемою, якщо це не так. Є кілька стратегій, як вирішити цю ситуацію:

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

Ідея заздалегідь створити бібліотеку обгортки зовсім не нова, але я рідко бачив, що це працює, оскільки вам доведеться робити припущення щодо майбутньої ситуації, для якої ви не знаєте, чи вдарить вас коли, і що виглядатиме "новий" фреймворк. З іншого боку, кілька років тому ми успішно обмінялися повною рамкою інтерфейсу в проекті C ++ з ~ 120 К рядків коду, застосовуючи стратегію адаптера, про яку я згадував вище.

— Док Браун
джерело

Звичайна інжекція конструктора взагалі не потребує рамки. Єдине, на чому ви втрачаєте, - це можливість централізувати свої залежності у конфігураційному файлі.

Контейнери DI - це модель "корпоративного програмного забезпечення", яка використовується, коли графік об'єкта дуже великий і складний. Я підозрюю, що 95% заявок цього не потребують.

— Роберт Харві
джерело

Я погоджуюсь, що малі проекти цього не потребують , але 95 +% проектів можуть отримати з цього прибуток .

— maaartinus

@maaartinus: Необхідна додаткова складність для мінімальної вигоди.

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

Що за? Це мої статистичні дані за клас: 0,5 анотація, 0,1 лінія конфігурації. То яка складність ви маєте на увазі ???

— maaartinus

@RobertHarvey: хоча я згодний на 100% з вашими твердженнями вище, ОП заявляє, що він уже запровадив рамки DI. Сказати йому "краще не" насправді не є відповіддю на його запитання.

— Doc Brown

@maaartinus, чим більше рамки автоматизовані, і тим більше матеріалів, які вона може вводити, тим складніше. Є конфігураційні файли XML, інжектор конструктора, введення властивостей, автоматичний зйомка об'єктів, ледача ін'єкція тощо тощо. Ці рамки DI можуть бути дуже складними.

— Реакційний

Я не думаю, що рамки DI можуть дійсно застаріти в будь-який час. Що має статися, щоб застаріти?

Можливо, винахід нового і розумнішого візерунка? Однак як би це виглядало, це вимагатиме значно більших змін у коді.
Можливо, зміна мови? Навіть гірше.

Я б сказав, що нинішній ДІ досить зрілий, і я не знаю, що там багато чого відбувається. Ви не вказали свою мову, тому, говорячи про Guice , вона досить ненав'язлива і працює зі стандартними анотаціями на Java (також використовує власну для речей, які не є стандартизованими, але вам це рідко потрібно). Він відкритий, широко використовується, і Apache має ліцензію. У чому може бути проблема?

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

— maaartinus
джерело