Dependency Injection в системе автоматизации сборок NUKE. Ответы на вопросы «зачем?» и «как?»

Вступление

Всем привет, сегодня поговорим о внедрении Dependency Injection (далее - DI) в Nuke и рассмотрим моё видение. Кто не знаком с Nuke вы можете ознакомиться или на официальном сайте или посмотреть вот эту презентацию, если коротко - то это очень удобная система автоматизации сборок, которая по факту консольное приложение на C#.

Специфика жизненного цикла Nuke

Помним, что Nuke - обычное консольное приложение, но если взглянуть на типичный пример метода Main() такого приложения:

class Program: NukeBuild, ICanDoSomething
{  
	static int Main(string[] args) => Execute<Program>(x => x.DefaultTarget);
}

Видно, что мы оформляем всю логику внутри класса, который наследуется от NukeBuild и передаем его через дженерик в метод Execute<T>(). Вся магия фреймворка начинается под капотом Execute<T>(), но из-за этого основной nuke-класс не может иметь конструктора с параметрами.

Также из-за того, что запуск фреймворка = передача метода через дженерик, появляется ещё одна особенность - функционал может быть "размазан" по nuke-классу и интерфейсам.

Для реализации DI наличие таргетов и в nuke-классе и в интерфейсах является слегка проблемой. Потому что не получится разместить DI контейнер в nuke-классе, ведь он должен быть доступен и для nuke-класса и для интерфейсов, единственный способ это реализовать - вынести контейнер в статический класс.

Зачем?

Nuke как фреймворк не имеет встроенной реализации DI и когда начинаешь использовать его необходимости в DI и не возникает. Ситуация меняется, когда Nuke начинает использовать достаточно широко и появляется необходимость в создании собственной библиотеки поверх него с целью вынести туда функционал, который можно переиспользовать.

При создании классов с функционалом, лично я, вижу 3 возможных варианта развития событий:

1. Весь функционал размещать в статических классах

2. Размещать функционал в НЕ статических классах и инициализировать их в контейнере nuke-класса

3. Размещать функционал в НЕ статических классах и использовать DI контейнер

Из этих 3-х вариантов мне больше всего импонирует DI, из-за того что:

• При использовании статических классов усложняется тестирование

• Иницализировать классы вручную слишком громоздко, потому что зачастую нужно передавать много зависимостей, а также вручную обновлять их при измениях

• При использовании DI контейнера появляется возможность регистрировать сервисы как Scoped

• Появляются гарантии, что при регистрации как Singleton в любом месте кода я получу один и тот же экземпляр класса

• И наверное основное - логика работы с зависимостями точно такая же как в привычных мне веб-проектах

Как?

Как я уже писал выше, в силу особенностей Nuke контейнер должен находится в статическом классе, я не придумал ничего лучше, как назвать его DependencyInjection. Этот класс нужен для хранения DI контейнера и обеспечения удобного доступа к нему. Также сразу озвучу некоторые важные для понимания кода моменты:

• Я использую встроенный в .NET Core IServiceProvider, если вам нравится DI из какого-то другого NuGet пакета - смысл будет таким же.

• В силу определенных причин в библиотеке я использую получаю сервисы из контейнера через IServiceScope, чтобы получать Scoped экземпляры класса для каждого таргета отдельно.

• Так как этот код у меня находится в библиотеке, в комментариях я использую слово "пользователь" имеется в виду когда библиотеку установили и к стандартным зависимостям добавили какие-то свои.

public static class DependencyInjection
{
  private static IServiceScope _scope; // Scope сервисов чтобы получать разные экземпляры класса для разных таргетов
  private static IServiceProvider _сontainer; // Непосредственно контейнер

  // Методы для получения экземпляров классов
  public static T Get<T>()
  {
    return _scope.ServiceProvider.GetService<T>() ?? throw new Exception($"Can`t get service {typeof(T).Name} from DI container");
  }
  
  public static object Get(Type type)
  {
    return _scope.ServiceProvider.GetService(type) ?? throw new Exception($"Can`t get service {type.Name} from DI container");
  }

  // Метод для того чтобы создать новый Scope
  public static void StartNewScope() => _scope = _сontainer.CreateScope();

  // Инициализирующий метод, в нём регистрируются все зависимости
  // [overrideDependencies] - параметр через какой добавляются зависимости пользователя
  internal static void RegisterDependencies(NukeBase nuke, Action<IServiceCollection> overrideDependencies)
  {
    //Создаем ServiceCollection где будем регистрировать зависимости
    var services = new ServiceCollection();

    services.AddSingleton(nuke);

 		// Место для регистрации зависимостей библиотеки
    // Например services.AddSingleton<SomeClass>();
    // Например services.AddScoped<SomeScopedClass>();

    var nukeDependencies = new ServiceCollection();
    overrideDependencies.Invoke(nukeDependencies); // получаем зависимости пользователя

    // проходимся по всем зависимостям пользователя
    // и добавляем или заменяем их в контейнер
    foreach (var dependency in nukeDependencies)
    {
      services.Replace(dependency);
    }
    
    //Собираем всё в кучу
    _сontainer = services.BuildServiceProvider();
    _scope = _сontainer.CreateScope();
  }
}

Теперь научим Nuke взаимодействовать с нашим контейнером. Начнём с создания абстрактного класса наследника NukeBase

public abstract partial class NukeBaseWithDI
{
  // Метод для регистрации пользовательских зависимостей
  protected virtual void AddOrOverrideDependencies(IServiceCollection services)
  {
  }
  
  // Метод для более лаконичного доступа к контейнеру 
  public static T Get<T>() => DependencyInjection.Get<T>();
  
  // Создаем отдельный scope для каждого таргета
  protected override void OnTargetRunning(string target)
  {
    DependencyInjection.StartNewScope();
    base.OnTargetRunning(target);
  }
}

Ещё DI может пригодится в интерфейсах, так как там используется реализация по умолчанию. Значит создадим базовый для всех таргетов интерфейс. Получается небольшое дублирование, но его тут не избежать(

public interface INukeTarget
{
  public T Get<T>() => DependencyInjection.Get<T>();
}

Теперь можно использовать это, например так:

class Program: NukeBaseWithDI
{
  static int Main(string[] args) => Execute<Program>(x => x.TestTarget);

  public Target TestTarget => _ => _
    .Executes(() => Get<TestService>().Run());

  protected override void AddOrOverrideDependencies(IServiceCollection services)
  {
    // Важный момент, так как может быть целая цепочка наследований
    // следует обязательно добавлять base.AddOrOverrideDependencies(services)
    base.AddOrOverrideDependencies(services);
    services.AddSingleton<TestService>();
  }
}

В примере выше, использование DI выглядит притянутым за уши, но когда классов и таргетов становится очень много всё становится на свои места. Кроме того основываясь на таком DI я сделал другие прикольные штуки в Nuke, о которых расскажу в следующих статьях, а пока можете почитать о Fail-fast design при автоматизации сборок с помощью Nuke там тоже используется такой DI подход.

Буду искренне рад замечаниям / пожеланиям, да и в целом вашим мыслям об этой статье в комментариях.