Рекомендуемый жизненный цикл для сервисов, использующих концентраторы SignalR - PullRequest
Новая
       25

Рекомендуемый жизненный цикл для сервисов, использующих концентраторы SignalR

1 голос
/ 09 апреля 2020

Я внедряю следующий сервис с SignalR ContentHub в различные контроллеры в веб-приложении ASP. NET Core (работает на. NET Core 2.2). В настоящее время сервис вводится с переходным жизненным циклом. Использование одного жизненного цикла было бы лучше? Является ли переходный жизненный цикл в этом случае возможным источником проблем с производительностью? 

public class PushMessageService : IPushMessageService
{
    private readonly ILogger<PushMessageService> _logger;
    private readonly IHubContext<ContentHub> _context;

    public PushMessageService(
        ILogger<PushMessageService> logger,
        IHubContext<ContentHub> context
    )
    {
        _logger = logger;
        _context = context;
    }    

    public async Task Push(int productId)
    {
        var msg = new Message
        {
            ProductId = productId
        };

        await SendAsync("PushMsg", productId, msg);
    }

    private async Task SendAsync<TPayload>(string methodName, int productId, TPayload payload)
    {
        await _context.Clients.Group("prod" + productId).SendAsync(methodName, payload);
    }
}

Ответы [ 2 ]

0 голосов
/ 09 апреля 2020

Абстракция IHubContext, которая окружает концентратор, является одиночной. Таким образом, время жизни класса, использующего его как зависимость, на самом деле не имеет значения. Независимо от того, используете ли вы одноэтапное, ограниченное или временное время жизни, вы всегда получаете один и тот же экземпляр.

0 голосов
/ 09 апреля 2020

SignalR ожидает, что концентратор будет создан отдельно для каждого сообщения. Вам нужно добавить его в качестве временной службы, если вы хотите, чтобы ваш концентратор был в DI. Как правило, вы не должны разрешать концентратор из DI. Если вам нужно совместно использовать код между вашим концентратором и каким-либо другим компонентом, я бы предложил использовать IHubContext или поместить общий код в отдельную службу DI, как вы делаете здесь. Поэтому я считаю, что это должно быть переходным процессом.

...