Добре застосована інверсія залежності залежить від гнучкості та стабільності на рівні всієї архітектури вашої програми. Це дозволить вашій програмі розвиватися більш безпечно та стабільно.
Традиційна багатошарова архітектура
Традиційно інтерфейс багатошарової архітектури залежав від бізнес-рівня, а це в свою чергу залежало від рівня доступу до даних.
Ви повинні розуміти шар, пакет чи бібліотеку. Подивимось, яким би був код.
У нас буде бібліотека або пакет для рівня доступу до даних.
// DataAccessLayer.dll
public class ProductDAO {
}
І ще одна логіка бізнесу бібліотеки чи пакету, що залежить від рівня доступу до даних.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private ProductDAO productDAO;
}
Шарувата архітектура з інверсією залежності
Інверсія залежності вказує на наступне:
Модулі високого рівня не повинні залежати від модулів низького рівня. Обидва повинні залежати від абстракцій.
Абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій.
Що таке модулі високого рівня та низький рівень? Мислячі модулі, такі як бібліотеки або пакети, модулем високого рівня будуть такі, від яких традиційно є залежності та низький рівень, від яких вони залежать.
Іншими словами, високий рівень модуля був би там, де викликається дія, і низький рівень, де виконується дія.
З цього принципу можна зробити розумний висновок про те, що між конкрементами не повинно бути залежності, але повинна бути залежність від абстракції. Але відповідно до прийнятого нами підходу ми можемо неправильно застосовувати залежність від інвестицій, а абстракцію.
Уявіть, що ми адаптуємо наш код наступним чином:
У нас буде бібліотека або пакет для рівня доступу до даних, який визначає абстракцію.
// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{
}
І ще одна логіка бізнесу бібліотеки чи пакету, що залежить від рівня доступу до даних.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private IProductDAO productDAO;
}
Хоча ми залежні від абстракції, залежність між бізнесом та доступом до даних залишається однаковою.
Щоб отримати інверсію залежності, інтерфейс стійкості повинен бути визначений в модулі або пакеті, де ця логіка або домен високого рівня, а не в модулі низького рівня.
Спочатку визначте, що таке доменний шар, і абстрагування його зв'язку визначається стійкістю.
// Domain.dll
public interface IProductRepository;
using DataAccessLayer;
public class ProductBO {
private IProductRepository productRepository;
}
Після того, як рівень стійкості залежить від домену, переходимо до інвертування зараз, якщо визначена залежність.
// Persistence.dll
public class ProductDAO : IProductRepository{
}
(джерело: xurxodev.com )
Поглиблення принципу
Важливо добре засвоїти концепцію, поглиблюючи мету та переваги. Якщо ми залишимось механічно та вивчимо типовий сховище випадків, ми не зможемо визначити, де ми можемо застосувати принцип залежності.
Але чому ми інвертуємо залежність? Яка головна мета поза конкретними прикладами?
Таке зазвичай дозволяє найчастіше змінювати найбільш стійкі речі, які не залежать від менш стійких речей.
Для типу стійкості легше змінити доступ до бази даних чи технології до тієї самої бази даних, ніж логіка домену або дії, призначені для постійної комунікації. Через це залежність повертається назад, оскільки так простіше змінити стійкість, якщо ця зміна відбудеться. Таким чином нам не доведеться змінювати домен. Доменний шар є найбільш стабільним з усіх, тому він не повинен залежати ні від чого.
Але є не лише цей приклад сховища. Існує багато сценаріїв, де застосовується цей принцип, і є архітектури, засновані на цьому принципі.
Архітектури
Є архітектури, де інверсія залежності є ключовою для її визначення. У всіх доменах це найважливіше, і саме абстракції вказують на протокол зв'язку між доменом та рештою пакетів або бібліотек.
Чиста архітектура
У чистій архітектурі домен розташований в центрі, і якщо ви дивитесь у напрямку стрілок, що вказують на залежність, зрозуміло, які є найважливіші та стабільні шари. Зовнішні шари вважаються нестабільними інструментами, тому уникайте залежно від них.
(джерело: 8thlight.com )
Гексагональна архітектура
Це відбувається так само з шестикутною архітектурою, де домен також розташований у центральній частині, а порти - це абстракції зв'язку від доміно назовні. Тут знову видно, що домен є найбільш стійкою і традиційна залежність перевернута.
