Все, что вам нужно знать о Scrutor и Autofac в C#

Давайте рассмотрим две популярные платформы внедрения зависимостей для dotnet и сравним Scrutor и Autofac на C#! Внедрение зависимостей становится (почти) необходимостью по мере того, как ваше приложение увеличивается в размерах и сложности, и использование правильной среды внедрения зависимостей может иметь огромное значение.

Начнем с краткого объяснения того, что такое внедрение зависимостей в C#: Внедрение зависимостей — это подход к проектированию, который позволяет объектам быть слабо связанными и продвигает концепцию передачи (или «внедрения») зависимостей, а не непосредственного создания их внутри класса. Это способствует модульности, тестируемости и гибкости вашей кодовой базы.

Так почему же так важно выбрать правильную инфраструктуру внедрения зависимостей для вашего C# проекты? Что ж, правильная среда может значительно упростить вашу кодовую базу, улучшить удобство сопровождения и повысить общую производительность вашего приложения. Scrutor и Autofac — два популярных варианта, и в этой статье мы их подробно сравним и проанализируем.

Обзор Scrutor и Autofac

Scrutor и Autofac — популярные платформы внедрения зависимостей в экосистеме C#. Они предоставляют разработчикам инструменты для эффективного управления зависимостями и продвижения модульных и расширяемых архитектур программного обеспечения (и нам здесь нравятся подобные вещи!). В этом разделе я кратко расскажу о Scrutor и Autofac, чтобы начать наше сравнение.

Скрутор на C

Scrutor — это легкое расширение для сканирования сборок на основе соглашений для контейнера .NET Core DI по умолчанию. Он упрощает регистрацию сервисов, позволяя разработчикам использовать соглашения на основе атрибутов, а не явную регистрацию. С помощью Scrutor вы можете определять правила и шаблоны, которые автоматически обнаруживают и регистрируют типы на основе определенных атрибутов или соглашений об именах.

Некоторые ключевые преимущества Scrutor включают:

1. Простота: Scrutor предлагает простой и интуитивно понятный API, который упрощает настройку и использование. Он упрощает процесс регистрации сервисов за счет использования соглашений, уменьшая необходимость регистрации вручную.
2. Гибкость: Scrutor позволяет динамически создавать и обнаруживать сервисы на основе соглашений. Такая гибкость позволяет разработчикам легко расширять и изменять архитектуру своего программного обеспечения без необходимости переписывать или изменять существующий код.
3. Производительность. Scrutor обеспечивает высокую производительность с минимальным влиянием на общую производительность приложения. Используя методы быстрого сканирования сборок, он обеспечивает эффективную регистрацию и разрешение сервисов.

Автофака в C

Autofac — это мощный и многофункциональный DI-контейнер для приложений .NET, и исторически я предпочитал именно его для внедрения зависимостей. Он предоставляет расширенные возможности и широкие возможности настройки, что делает его подходящим для сложных проектов. Autofac предлагает множество функций и расширений, которые позволяют разработчикам обеспечить детальный контроль над внедрением зависимостей, но это также может сделать его слишком сложным для многих случаев использования.

Вот некоторые ключевые преимущества Autofac:

1. Расширяемость: Autofac предоставляет модульную и расширяемую архитектуру, позволяющую разработчикам настраивать и расширять ее поведение в соответствии с конкретными требованиями. Он предлагает широкий спектр точек расширения и вариантов интеграции, что делает его легко адаптируемым к различным потребностям проекта.
2. Управление сроком действия: Autofac предлагает различные варианты управления сроком действия зарегистрированных служб, включая одноэлементные, по запросу и по зависимостям. Такая гибкость обеспечивает эффективное использование ресурсов и позволяет разработчикам контролировать срок действия зависимостей.
3. Взаимодействие: Autofac легко интегрируется с другими популярными платформами и технологиями в экосистеме .NET. Независимо от того, разрабатываете ли вы приложения ASP.NET Core или работаете со сторонними библиотеками, Autofac предоставляет возможности плавной интеграции, обеспечивая удобство разработки.

Scrutor и Autofac — отличные варианты внедрения зависимостей в приложениях C#. Scrutor предлагает легкий и основанный на соглашениях подход, упрощающий регистрацию услуг, а Autofac обеспечивает широкие возможности настройки и расширенные функции для сложных проектов. В зависимости от конкретных потребностей и сложности вашего проекта вы можете выбрать фреймворк, который лучше всего соответствует вашим требованиям — здесь не существует универсального «лучшего».

---

Ключевые различия Scrutor и Autofac в C

При сравнении Scrutor и Autofac для внедрения зависимостей в C# следует учитывать несколько ключевых отличий. В этом разделе мы рассмотрим эти различия с точки зрения ключевых функций, синтаксиса и использования, а также их подхода к регистрации и разрешению зависимостей.

Основные особенности этих платформ

В общем, Scrutor — это легкая библиотека, предлагающая простой и интуитивно понятный способ сканирования сборок и применения соглашений для регистрации зависимостей. Он предоставляет мощные возможности фильтрации, позволяя разработчикам легко указывать, какие типы следует включать или исключать в процессе сканирования. Но настоящее преимущество, на мой взгляд, заключается в простоте и беспрепятственной работе с IServiceCollection.

С другой стороны, Autofac — более надежный и многофункциональный контейнер для внедрения зависимостей. Он предлагает более продвинутые функции, такие как области экземпляров, управление жизненным циклом, перехват, система модулей и интеграция с другими платформами. Это также означает IServiceCollection, который мы получаем в приложениях ASP.NET Core, но я признаю, что это выглядит немного более неуклюже.

Различия в синтаксисе и использовании

Что касается синтаксиса и использования, Scrutor и Autofac предоставляют понятные и лаконичные API для регистрации и разрешения зависимостей. Однако они различаются в своем подходе.

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

Autofac, с другой стороны, использует более традиционный и явный синтаксис для регистрации. Разработчикам необходимо явно указать сопоставление между интерфейсами и конкретными реализациями, используя гибкий API регистрации. Хотя для этого требуется больше ручной настройки по сравнению с подходом Scrutor, основанным на соглашениях, он обеспечивает больше контроля и гибкости для сложных сценариев.

Я обнаружил, что мне пришлось создать свой собственный решения для сканирования зависимостей для Autofac, хотя они очень просты и требуют некоторой рефлексии. В этом видео вы можете увидеть, как я управляю сканированием зависимостей для Autofac:

https://www.youtube.com/watch?v=L8KeFxUWaGM&themeRefresh =1&embedable=true

---

Примеры кода: использование Scrutor для внедрения зависимостей в C

В этом разделе я предоставлю вам примеры кода и пошаговое руководство по использованию Scrutor для внедрения зависимостей в C#. Конечно, это будет надуманный пример, поэтому вам захочется адаптировать приведенные здесь концепции к *вашей* ситуации. Как бы мне ни хотелось предоставить вам код копирования и вставки, я не могу знать структуру каждого приложения. Вы предупреждены! 🙂

1 – Установка Scrutor на C

Для начала убедитесь, что в вашем проекте установлен Scrutor. Это можно сделать, добавив в решение пакет NuGet Scrutor. На момент написания 4.2.2 является последней доступной версией Scrutor. Конечно, вы можете найти дополнительную информацию о Scrutor на C#, прежде чем углубляться в подробности, проверив ее на GitHub.

2 – Настройка контейнера зависимостей для Scrutor на C

Во-первых, давайте начнем с настройки DI-контейнера в классе запуска вашего приложения. Вот пример использования контейнера DI по умолчанию в ASP.NET Core:

using Microsoft.Extensions.DependencyInjection;
using Scrutor;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.Scan(scan => scan
            .FromAssemblyOf<Startup>()
            .AddClasses()
            .AsMatchingInterface()
            .WithScopedLifetime()
        );

        // Add other services and configurations here
    }
}

В приведенном выше коде services.Scan используется для сканирования сборок и регистрации типов с соответствующими интерфейсами. Метод FromAssemblyOf<Startup> указывает, какую сборку нужно сканировать. Метод AddClasses() выбирает все классы для регистрации, а метод AsMatchingInterface() указывает, что каждый класс должен быть зарегистрирован с соответствующим ему интерфейсом. Наконец, метод WithScopedLifetime() определяет время жизни сервисов, область которых должна быть ограничена.

3 – Пример сервиса в нашем приложении

Давайте продолжим создание примера интерфейса и его соответствующей реализации. Предположим, у нас есть интерфейс IEmailService и класс EmailService, реализующий его:

public interface IEmailService
{
    void SendEmail(string recipient, string message);
}

public class EmailService : IEmailService
{
    public void SendEmail(string recipient, string message)
    {
        // Code to send email
    }
}

4 – Использование зарегистрированных сервисов с помощью Scrutor

Теперь мы можем использовать зарегистрированные сервисы с помощью внедрения конструктора. Предположим, у нас есть HomeController, для которого требуется IEmailService:

public class HomeController : Controller
{
    private readonly IEmailService _emailService;

    public HomeController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public IActionResult Index()
    {
        // Use the email service to send emails
        _emailService.SendEmail("[email protected]", "Hello, Scrutor!");

        return View();
    }
}

В приведенном выше коде класс HomeController имеет конструктор, который принимает зависимость IEmailService. Контейнер DI заботится о внедрении реализации EmailService при создании экземпляра HomeController.

---

Примеры кода: использование Autofac для внедрения зависимостей в C

В этом разделе я предоставлю пошаговое руководство по использованию Autofac для внедрения зависимостей в C#. Я приведу фрагменты кода и пояснения, которые помогут вам понять процесс.

1 – Установка Autofac

Прежде чем мы сможем начать использовать Autofac для внедрения зависимостей, нам необходимо установить необходимые пакеты. Откройте свой проект в Visual Studio и перейдите к диспетчеру пакетов NuGet. Найдите «Autofac» и установите пакет.

2 – Настройка контейнера в Autofac

После установки пакета мы можем приступить к настройке контейнера Autofac. Контейнер отвечает за управление и разрешение зависимостей в нашем приложении. В своем проекте откройте Startup.cs или аналогичный файл, в котором вы настраиваете свои службы.

Сначала добавьте необходимые пространства имен в начало файла:

using Autofac;
using Autofac.Extensions.DependencyInjection;

Затем создайте метод для настройки контейнера Autofac:

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    var builder = new ContainerBuilder();

    // Add your services and dependencies here

    builder.Populate(services);

    var container = builder.Build();

    return new AutofacServiceProvider(container);
}

В методе ConfigureServices создайте экземпляр класса ContainerBuilder. Этот класс будет использоваться для регистрации ваших сервисов и зависимостей. Заполните контейнер службами из параметра services, а затем создайте контейнер.

Наконец, верните новый экземпляр класса AutofacServiceProvider, передав контейнер в качестве параметра.

3 – Регистрация сервисов в Autofac

Когда контейнер настроен, мы можем зарегистрировать наши сервисы и зависимости. В методе ConfigureServices вы можете использовать экземпляр builder для регистрации своих служб.

Вот пример регистрации службы с одной реализацией:

builder.RegisterType<MyService>().As<IMyService>();

В этом примере мы регистрируем MyService как реализацию IMyService. Это означает, что всякий раз, когда запрашивается IMyService, Autofac предоставляет экземпляр MyService.

Вы также можете зарегистрировать несколько реализаций интерфейса с помощью метода RegisterType:

builder.RegisterType<MyService1>().As<IMyService>();
builder.RegisterType<MyService2>().As<IMyService>();

В этом случае существует две реализации IMyService, MyService1 и MyService2. Всякий раз, когда запрашивается IMyService, Autofac предоставляет экземпляр либо MyService1, либо MyService2.

4 – Разрешение зависимостей в Autofac

Теперь, когда наши службы зарегистрированы, мы можем разрешить их с помощью контейнера Autofac. В ваших классах, где вам нужно использовать зависимость, вы можете добавить параметр конструктора типа зависимости.

public class MyController
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    }

    // Use _myService in your methods
}

В этом примере MyController зависит от IMyService. Добавив его в качестве параметра конструктора, Autofac автоматически разрешит и предоставит экземпляр IMyService при создании нового экземпляра MyController.

---

Модульное приложение C# с поддержкой плагинов

В модульном приложении C# с поддержкой плагинов внедрение зависимостей становится жизненно важным для беспрепятственной интеграции и управления плагинами. Мне трудно представить, как кому-то может понадобиться вручную подключать такие вещи или создавать собственную систему загрузки зависимостей/плагинов… особенно когда эти вещи работают так хорошо «из коробки»! Давайте посмотрим, как Scrutor и Autofac можно применить для эффективной обработки этого сценария.

Пример кода: использование Scrutor в C# для сканирования

С помощью Scrutor мы можем использовать метод Assemblies.FromPath для динамического сканирования и регистрации сборок. Это позволяет нам обнаруживать и регистрировать плагины во время выполнения.

public void ConfigureServices(IServiceCollection services)
{
    services.Scan(scan => scan
        .FromAssembliesFromPath(
            AppDomain.CurrentDomain.BaseDirectory,
            "SomePluginAssemblies")
        .AddClasses()
        .AsImplementedInterfaces()
        .WithTransientLifetime());
}

Пример кода: использование Autofac в C# для сканирования

Autofac предоставляет аналогичную возможность с помощью своего класса AssemblyFinder, позволяя нам динамически сканировать и регистрировать сборки. Для этого мы можем использовать метод RegisterAssemblyTypes.

public void ConfigureContainer(ContainerBuilder builder)
{
    var assemblyFinder = new AssemblyFinder();
    var pluginAssemblies = assemblyFinder.GetAssembliesInFolder("SomePluginAssemblies");

    builder.RegisterAssemblyTypes(pluginAssemblies)
        .AsImplementedInterfaces()
        .InstancePerLifetimeScope();
}

---

Подведение итогов Scrutor и Autofac в C

В этой статье мы сравнивали Scrutor и Autofac на C# с целью понять различия между этими двумя платформами внедрения зависимостей в C#. Мы рассмотрели их особенности, преимущества и варианты использования на примерах кода, чтобы дать читателям четкое представление о том, как они работают на практике.

При выборе между Scrutor и Autofac на C# важно учитывать такие факторы, как сложность проекта, требования к производительности, поддержка сообщества и личное знакомство с платформами. Простота и гибкость Scrutor делают его хорошим выбором для небольших и средних проектов или ситуаций, когда предпочтительна быстрая разработка и регистрация на основе соглашений. Autofac с его расширенными функциями и развитой экосистемой хорошо подходит для сложных приложений корпоративного уровня, требующих обширной настройки и детального контроля над процессом внедрения зависимостей.

В конце концов, вам нужно будет вместе со своей командой решить, что лучше подойдет. Но любой из этих двух вариантов, вероятно, будет лучше, чем полное отсутствие внедрения зависимостей! Если эта информация оказалась для вас полезной и вы ищете дополнительные возможности для обучения, рассмотрите возможность подписаться на мой бесплатный еженедельный информационный бюллетень по разработке программного обеспечения и просмотреть мой бесплатные видео на YouTube!

:::информация Также опубликовано здесь

:::

---

Оригинал