Где создать экземпляр класса, который занимается сервисными событиями в .NET Core?

Question

Проблема, с которой я сталкиваюсь, связана с дизайном и структурным подходом, когда в ASP.NET Core нужно обрабатывать события службы, где мне создавать экземпляр класса / интерфейса, который это делает?Я могу, например, зарегистрировать область для MyClass, которая будет вводить MyService через конструктор, но опять же, где применить этот MyClass к жизни?

Я создал службу и зарегистрировал ее как синглтонную область, службавыполняется.

    public IServiceProvider ConfigureServices(IServiceCollection services)
    {
        services.AddEntityFrameworkSqlServer()
            .AddDbContext<Senseflow.Database.SolutionModuleContext>(opts => opts.UseSqlServer
            (Configuration.GetConnectionString("Database")));

        services.Configure<MQTTConfig>(Configuration.GetSection("MQTT"))
            .AddSingleton<Microsoft.Extensions.Hosting.IHostedService, MQTTService>();

        services.AddMvc()
            .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

        var container = ContainerConfig.Build();
        container.Populate(services);
        AppContainer = container.Build();

        return new AutofacServiceProvider(AppContainer);
    }

Теперь, как вы видите, MQTTService зарегистрирован и работает.Какой подход я должен предпринять, чтобы зарегистрировать MyClass, который будет обрабатывать, скажем, «EventX», который запускается MQTTService?И где его создать / внедрить?

Answer 1

Ваше веб-приложение. Обычно классы создаются в ответ на веб-запрос. Когда приложение получает запрос, оно создает контроллер, а затем, если другие классы вводятся в контроллер, оно создает их и так далее.

Это делает неясным, как реагирует на события из MQTTService, поскольку из этого следует, что ваши контроллеры отвечают на веб-запросы, а не на события из MQTTService.

Вот что я мог бы сделать, если целью приложения было только для ответа на события MQTTService. Вы можете сделать то же самое в веб-приложении:

Сначала определите ваш класс, который реагирует на события, вставьте в него MQTTService и назначьте обработчики событий. Кстати, я предполагаю, что вы используете код, найденный на этой странице :

public class MqttServiceEventListener // first name that popped into my head
{
    private readonly MQTTService _mqttService;

    public MqttServiceEventListener(MQTTService mqttService)
    {
        _mqttService = mqttService;

        // add event handlers
    }
}

Зарегистрируйте этот класс в ConfigureServices. Это потому, что вы можете добавить в этот класс другие зависимости, которые необходимы для обработки событий. Пока все зарегистрировано в IServiceCollection, вы сможете разрешить весь этот класс из контейнера.

Далее вам понадобится экземпляр MqttServiceEventListener. Он может принадлежать статическому классу или t, но если он не будет создан в ответ на веб-запросы, тогда другое решение - просто создать экземпляр при запуске и заставить его прослушивать события. Есть несколько способов сделать это, и предпочтения будут другими.

Вы можете сделать это:

public static class MqttServiceEventListenerExtensions
{
    private static MqttServiceEventListener _eventListener;

    public static void UseMqttServiceEventListener(this IApplicationBuilder app)
    {
        if (_eventListener == null) return; //or throw an InvalidOperationException

        _eventListener = app.ApplicationServices.GetService<MqttServiceEventListener>();
    }
}

Теперь, в Startup.Configure, позвоните по этому номеру:

app.UseMqttServiceEventListener();

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

Если классы, зарегистрированные как одиночные, плохи в вашем сценарии:

Аналогичным вариантом может быть пропустить статический экземпляр прослушивателя событий и просто зарегистрировать класс, который обрабатывает события (или даже разные классы для обработки разных событий), например:

public class MqttServiceEventHandler
{
    public void MqttServerClientConnected(object sender, MqttClientConnectedEventArgs e)
    {
        // handle the event
    }
}

То же самое - зарегистрировать обработчики событий в контейнере IServiceProvider. Если им нужно короткое время жизни, вы можете сделать их кратковременными.

Теперь, в вашем классе расширения, сделайте это вместо:

public static class MqttServiceEventListenerExtensions
{
    private static MQTTService _mqttService; // likely unnecessary

    public static void UseMqttServiceEventListener(this IApplicationBuilder app)
    {
        var serviceProvider = app.ApplicationServices;

        // This is registered as a singleton, so there's only going to be on instance.

        _mqttService = serviceProvider.GetService<MQTTService>();

        // Add event handlers that resolve the needed class and pass the
        // event to it.

        _mqttService.ClientDisconnected += (sender, eventArgs) =>
        {
            var handler = serviceProvider.GetService<MqttServiceEventHandler>();
            handler.MqttServerClientConnected(sender, eventArgs);
        };
    }
}

И то же самое в Startup.Configure: app.UseMqttServiceEventListener();

Сначала вы решаете MQTTService, который вы зарегистрировали как одиночный, поэтому поставщик услуг всегда будет возвращать один и тот же экземпляр. Это спорный вопрос, нужно ли на самом деле хранить ссылку на него в классе. Вы всегда можете удалить _mqttService, разрешить MQTTService как локальную переменную и добавить к ней обработчики событий.

Затем вы добавляете обработчики событий, которые разрешают класс, необходимый для обработки события, а затем передают ему аргументы события. Опять же, это требует, чтобы все эти классы были зарегистрированы заранее. Но это хорошо, потому что это означает, что вы можете добавить больше зависимостей в эти классы, если это необходимо, и так далее.

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