Dependency Injection (DI) следует использовать везде .Однако обратите внимание, что DI - это всего лишь набор шаблонов, а не фреймворк или библиотека.Лучший способ думать о DI - это то, что это слабосвязанный код , включаемый Constructor Injection .Вы можете написать DI-дружественный код полностью, даже не обращаясь к DI-контейнеру или используя анти-паттерн Service Locator .
Следующий вопрос, который приходит на умто есть где должны быть составлены компоненты? Это, вероятно, то, что подразумевается под первоначальным утверждением: only compose приложение на самом внешнем уровне - UI или(веб) интерфейс сервиса.Это то, что я называю Композиционный корень .Остальной код остается модульным и гибким.
В корне композиции вы можете использовать DI для бедного человека или соответствующий DI-контейнер .Я настоятельно рекомендую вам использовать DI-контейнер, но это не обязательно.
Чтобы проиллюстрировать, что я имею в виду под DI, вот пример:
public class Foo : IFoo
{
private readonly IBar bar;
public Foo(IBar bar)
{
if (bar == null)
{
throw new ArgumentNullException("bar");
}
this.bar = bar;
}
public IBaz Baz(ISnafu snafu)
{
return this.bar.Snafize(snafu).ToBaz();
}
}
Реализация IBaz может быть реализована в виде полностью отдельная библиотека от той, которая определяет класс Foo.Кроме того, потребителям, находящимся выше в стеке, не нужно ничего знать о Foo и IBar - они могут просто потреблять IFoo:
public class MyClass : ISomeInterface
{
private readonly IFoo foo;
public MyClass(IFoo foo)
{
if (foo == null)
{
throw new ArgumentNullException("foo");
}
this.foo = foo;
}
// ...
}
Это обеспечивает слабую связь, которая является мотивацией для DI.Повторите столько, сколько необходимо.