Внедрение зависимостей в .Net Марка Симана 2 — Внедрение конструктора, время жизни
Зависимости между слоями приложения | Внедрение конструктора, время жизни
Продолжаем борьбу за слабую связанность. В предыдущей заметке мы рассмотрели зависимости между слоями приложения, прейдем к меньшим формам.
Агрегация, внедрение конструктора
Объекты/классы системы, как и слои, взаимодействуют друг с другом. Между классами тоже есть зависимости.
Например, в листинге 1 MyService использует MyDataContext (EF) — имеет зависимость MyDataContext.
class MyService
{
public void DoSomething()
{
using(var dbCtx = new MyDataContext())
{
// используем dbCtx
}
}
}
Листинг 1. Сильная зависимость MyService от MyDataContext
У кода выше есть недостатки:
— используется антипаттерн «Диктатор»: MyService сам создает и контролирует время жизни свой зависимости MyDataContext.
— нарушен принцип инверсии зависимости (Dependency Inversion Principle, DIP) (куда же в «наукообразной» статье без SOLID): MyService зависит от конкретной реализации MyDataContext, было бы лучше использовать интерфейс/абстрактный класс.
Принцип инверсии зависимости (Dependency Inversion Principle, DIP)Фактически синоним для требования «Программировать в соответствии с интерфейсом, а не с конкретной реализацией».
(цитата из книги)
Улучшим код с помощью агрегации — листинг 2:
class MyService
{
private readonly IRepository Repository;
public MyService(IRepository repository){
if(repository == null)
throw new ArgumentNullException(nameof(repository));
Repository = repository;
}
public void DoSomething()
{
// используем Repository
}
}
Листинг 2. Агрегация. MyService не создает и не управляет временем жизни свой зависимости Repository
Отступление:
Хорошая статья про агрегацию и композицию написана Сергеем Тепляковым. Кроме прочего статья научит вас рисовать умные схемы. В качестве спойлера: какая схема описывает агрегацию?
Рис 1. Схемы композиции и агрегации
Вернемся к листингу 2. Это и есть внедрение зависимости, при том лучший вариант — «Внедрение конструктора». Связанность уменьшилась, но появился вопрос: как же вызвать Dispose репозитория? Помните в листинге 1 использовался Using?
Класс, передавший управление своими зависимостями, теряет более чем просто возможность выбирать конкретные реализации абстракций. Он также теряет возможность управления как моментом создания экземпляра, так и моментом, когда этот экземпляр становится недоступным.
(цитата из книги)
Интересное замечание: если класс имеет более 4-х зависимостей (более 4-х параметров конструктора) — это повод задуматься над рефакторингом. Похоже, что объект выполняет слишком много функций, нарушается принцип единичной ответственности (Single Responsibility Principle, SRP — опять SOLID).
Время жизни зависимостей
Отвечая на вопрос «как же вызвать Dispose репозитория?» Марк предлагает пойти на компромисс. MyService не должен знать об особенностях реализации IRepository, в том числе о необходимости освобождения ресурсов. Т.е. вот такое определение IRepository нежелательно:
interface IRepository : IDisposable
{
void DeleteProduct(int id);
}
Кроме того, что такой интерфейс открывает потребителю (MyService) часть знания о конкретной реализации, он еще накладывает ограничение на возможные реализации — они должны реализовать IDisposable (может он им не нужен).
А в имплементации IRepository это знание, о реализации, допускается — листинг 3.
class SqlRepository : IRepository
{
IDataContextFactory DbContextFactory;
public SqlRepository(IDataContextFactory dbContextFactory)
{
if(dbContextFactory == null)
throw new ArgumentNullException(nameof(dbContextFactory));
DbContextFactory = dbContextFactory;
}
public void DeleteProduct(int id);
{
using(var dbCtx = DbContextFactory.Create())
{
// использование dbCtx
}
}
}
Листинг 3. Реализация IRepository инкапсулирует работу с базой данных
Дополнение (не самое главное): SqlRepository управляет временем жизни DataConext, но создание вынесено в фабрику.
В этом и заключается компромисс: да, SqlRepository управляет временем жизни DataContext, но это не влияет на остальной код.
Выше описано хорошее решение, но применить его не всегда возможно. Например, нужна транзакционность:
public void DoSomething(int productId)
{
this.Repository.DeleteProduct(productId);
this.Repository.DeleteHistory(productId);
}
Листинг 4. Удаление продукта и истории должно выполняться в одной транзакции
Если удаление истории завершается ошибкой, удаление продукта должны быть отменено (по умному это паттерн Unit of Work). Тогда комитить в базу отдельно в методах DeleteProduct и DeleteHistory нельзя. Как же быть? Вы знаете, где искать ответ.
Продолжение следует
Мы рассмотрели основной прием внедрения завистей: агрегация, реализованная с помощью внедрения конструктора. Коснулись темы управления временем жизни объектов. До новых встреч.
