Эффективное применение инверсии зависимостей дает гибкость и стабильность на уровне всей архитектуры вашего приложения. Это позволит вашему приложению развиваться более безопасно и стабильно.
Традиционная многоуровневая архитектура
Традиционно пользовательский интерфейс многоуровневой архитектуры зависел от бизнес-уровня, а это, в свою очередь, зависело от уровня доступа к данным.
Вы должны понимать слой, пакет или библиотеку. Посмотрим, как будет выглядеть код.
У нас была бы библиотека или пакет для слоя доступа к данным.
// 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 )
Шестиугольная архитектура
То же самое происходит с гексагональной архитектурой, где домен также расположен в центральной части, а порты являются абстракциями коммуникации от внешнего мира домино. Здесь снова очевидно, что область является наиболее устойчивой и традиционная зависимость является инвертированной.
