Dobrze zastosowana inwersja zależności zapewnia elastyczność i stabilność na poziomie całej architektury aplikacji. Umożliwi to bezpieczniejszą i stabilniejszą ewolucję aplikacji.
Tradycyjna architektura warstwowa
Tradycyjnie interfejs użytkownika architektury warstwowej zależał od warstwy biznesowej, a to z kolei zależało od warstwy dostępu do danych.
Musisz zrozumieć warstwę, pakiet lub bibliotekę. Zobaczmy, jak wyglądałby kod.
Mielibyśmy bibliotekę lub pakiet dla warstwy dostępu do danych.
// DataAccessLayer.dll
public class ProductDAO {
}
I kolejna logika biznesowa biblioteki lub warstwy pakietu, która zależy od warstwy dostępu do danych.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private ProductDAO productDAO;
}
Architektura warstwowa z odwróceniem zależności
Odwrócenie zależności wskazuje, co następuje:
Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Obie powinny zależeć od abstrakcji.
Abstrakcje nie powinny zależeć od szczegółów. Szczegóły powinny zależeć od abstrakcji.
Jakie są moduły wysokiego poziomu i niskiego poziomu? Myśląc o modułach, takich jak biblioteki lub pakiety, moduł wysokiego poziomu to te, które tradycyjnie mają zależności i niski poziom, od których zależą.
Innymi słowy, wysoki poziom modułu byłby miejscem wywołania akcji, a niski - miejscem wykonywania akcji.
Rozsądny wniosek, jaki można wyciągnąć z tej zasady, jest taki, że nie powinno być zależności między konkrecjami, ale musi istnieć zależność od abstrakcji. Ale zgodnie z przyjętym podejściem możemy niewłaściwie zastosować zależność od inwestycji, ale abstrakcję.
Wyobraź sobie, że dostosowujemy nasz kod w następujący sposób:
Mielibyśmy bibliotekę lub pakiet dla warstwy dostępu do danych, która definiuje abstrakcję.
// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{
}
I kolejna logika biznesowa biblioteki lub warstwy pakietu, która zależy od warstwy dostępu do danych.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private IProductDAO productDAO;
}
Chociaż jesteśmy uzależnieni od abstrakcji, zależność między biznesem a dostępem do danych pozostaje taka sama.
Aby uzyskać odwrócenie zależności, interfejs trwałości musi być zdefiniowany w module lub pakiecie, w którym znajduje się ta logika lub domena wysokiego poziomu, a nie w module niskiego poziomu.
Najpierw zdefiniuj, czym jest warstwa domeny, a abstrakcją jej komunikacji jest zdefiniowana trwałość.
// Domain.dll
public interface IProductRepository;
using DataAccessLayer;
public class ProductBO {
private IProductRepository productRepository;
}
Po warstwie trwałości zależy od domeny, należy teraz odwrócić, jeśli zależność jest zdefiniowana.
// Persistence.dll
public class ProductDAO : IProductRepository{
}
(źródło: xurxodev.com )
Pogłębienie zasady
Ważne jest, aby dobrze przyswoić sobie tę koncepcję, pogłębiając cel i korzyści. Jeśli pozostaniemy mechanicznie i nauczymy się typowego repozytorium przypadków, nie będziemy w stanie zidentyfikować, gdzie możemy zastosować zasadę zależności.
Ale dlaczego odwracamy zależność? Jaki jest główny cel poza konkretnymi przykładami?
Zwykle pozwala to na częstsze zmiany rzeczy najbardziej stabilnych, które nie są zależne od rzeczy mniej stabilnych.
Łatwiej jest zmienić typ trwałości, czyli bazę danych lub technologię dostępu do tej samej bazy danych niż logika domeny lub akcje zaprojektowane do komunikacji z trwałością. Z tego powodu zależność jest odwrócona, ponieważ łatwiej jest zmienić trwałość, jeśli ta zmiana nastąpi. W ten sposób nie będziemy musieli zmieniać domeny. Warstwa domeny jest najbardziej stabilna ze wszystkich, dlatego nie powinna od niczego zależeć.
Ale nie ma tylko tego przykładu repozytorium. Istnieje wiele scenariuszy, w których ta zasada ma zastosowanie, i istnieją architektury oparte na tej zasadzie.
Architektury
Istnieją architektury, w których inwersja zależności jest kluczem do jej definicji. We wszystkich domenach jest najważniejszy i to abstrakcje wskażą, jaki protokół komunikacyjny pomiędzy domeną a pozostałymi pakietami czy bibliotekami jest zdefiniowany.
Czysta architektura
W czystej architekturze domena znajduje się w centrum i jeśli spojrzy się w kierunku strzałek wskazujących na zależności, widać, jakie warstwy są najważniejsze i stabilne. Warstwy zewnętrzne są uważane za niestabilne narzędzia, więc unikaj polegania na nich.
(źródło: 8thlight.com )
Architektura sześciokątna
Podobnie dzieje się z architekturą heksagonalną, w której domena znajduje się również w części centralnej, a porty są abstrakcjami komunikacji wychodzącej z domina na zewnątrz. Tutaj znowu widać, że domena jest najbardziej stabilna, a tradycyjna zależność jest odwrócona.
