IoC & Dependency Injection

Dependency Injection,
IoC

План

IoC принцип

Dependency injection

Как не стоит определять зависимости

Простой пример

Термины

Сервис - объект, который может выполняет какую-либо
требуемую функцию

Клиент - тот, кто использует сервис

Зависимость - сервис, который требуется другому объекту
для выполнения каких-либо функций

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

IoC, истоки
public class Reporter
{
     public void SendReports()
     {
        var reportBuilder = new
ReportBuilder();
        var report =
reportBuilder.CreateReport();
        var reportSender = new
EmailReportSender();
        reportSender.Send(report);
    }
}

Что хорошего?

Это просто

Что плохого?

Это нетестируемо

Это сильное связывание, которое
приводит к монолитности OOD

В итоге это превращается в ад

Эволюция
{
     {
        var reportBuilder =
ServiceLocator.ReportBuilder;
        var report =
        var reportSender =
ServiceLocator.ReportSender;
    }
}

Стало лучше, но...

Мы должны поддерживать ServiceLocator

Зависимый объект всё равно
определяет свои зависимости внутри
реализации

Зависимости неочевидны

IoC approach
{
private readonly IReportBuilder _builder;
private readonly IReportSender _sender;

public Reporter(IReportBuilder builder,
IReportSender sender)
{
_builder = builder;
_sender = sender;
}
     {
        var report = _builder.CreateReport();
        _sender.Send(report);
    }
}

IoC approach

ReportSender не может определить свои
зависимости самостоятельно

Зависимости очевидны

Тестировать проще

Слабосвязанная архитектура

DI with IoC containers

Ответсвенность за внедрение
зависимостей перекладывается на
специальный фреймворк (IoC container)

Зависимости конфигурируются в коде
или конфиг-файлах

DI with IoC containers

var reporter = container.Get<Reporter>();
reporter.SendReports();

Антипаттерны IoC

Control Freak

Bastard injection

Constrained injection

Service locator

Property injection *

Control Freak /
Диктатор-наркоман :)
{
     {
        var reportBuilder = new
ReportBuilder();
        var report =
        var reportSender = new
EmailReportSender();
    }
}

Bastard injection /
внебрачные зависимости
{
private readonly IReportBuilder _builder;
private readonly IReportSender _sender;

public Reporter(IReportBuilder builder,
IReportSender sender)
{
_builder = builder;
_sender = sender;
}

public Reporter()
this(ReportBuilder.GetDefaultBuilder(),
ReportSender.GetDefaultSender())
{
_builder = builder;
_sender = sender;
}
}

Constrained construction /
ограниченное построение

Type bulderType = GetBuilderType();
Type senderType = GetSenderType();
Reporter reporter =
Activator.CreateInstance(typeof(Reporter)
, builderType, senderType);

Service locator
{
     {
        var reportBuilder =
ServiceLocator.Get<IReportBuilder>();
        var report =
        var reportSender =
ServiceLocator.Get<IReportSender>();
    }
}


Не антипаттерн в класическом понимании, но
требует осторожности

Используйте только тогда, когда это
дейтствительно нужно (какой-либо фреймворк
требует конструктор без параметров)

Используйте тогда, когда поведение объкта
меняется во время выполнения


{
public IReportBuilder Builder { get;set; }
public IReportSender Sender { get;set; }
     {
        var report = Builder.CreateReport();
        Sender.Send(report);
    }
}


Можно изменить зависимости во время
выполнения (например, при смене
настроек без перезапуска приложения)

Если забыть определить зависимости, то
получим исключение на этапе
выполнения

.NET DI/IoC frameworks

Unity

Ninject

Autofac

StructureMap

Castle Windsor

IoC & Dependency Injection

More Related Content

Similar to IoC & Dependency Injection (20)

IoC & Dependency Injection