Несколько концентраторов к одному подключению, чтобы предотвратить класс бога

Из здесь, говорится, что

Все клиенты будут использовать один и тот же URL-адрес для установления соединения SignalR с вашей службой (/ signalr или ваш пользовательский URL-адрес, если вы его указали), и это соединение используется для всех концентраторов, определенных службой.

Нет разницы в производительности для нескольких концентраторов по сравнению с определением всех функций концентратора в одном классе.

Причина, по которой я хочу это сделать, только потому, что мой единственный концентратор становится классом бога, однако я не могу найти способ сделать несколько концентраторов в .NET Core (при совместном использовании одного соединения). Если бы я мог это сделать, тогда я мог бы управлять своим кодом, как в веб-API.

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

Кто-то из здесь заявляет, что сопоставление методов с внешними классами - это обходной путь. Это единственный обходной путь?


person Lee Song    schedule 20.12.2018    source источник


Ответы (2)


Поскольку SignalR интегрирован в ASP.NET Core, это невозможно больше, чтобы использовать одно соединение для нескольких концентраторов:

В ASP.NET Core SignalR модель подключения была упрощена. Подключения выполняются напрямую к одному концентратору, а не к одному соединению, используемому для совместного доступа к нескольким концентраторам.


В качестве обходного пути для класса god вы можете использовать _ 1_ для структурирования вашего кода, если вы хотите использовать один концентратор.

Однако я действительно рекомендую использовать разные концентраторы для каждой цели. Например: если у меня есть система чата, я бы использовал специальный хаб (ChatHub) для чата. Если бы у меня также была система викторин, я бы использовал QuizHub и т. Д.

Я действительно не вижу проблемы с обработкой нескольких подключений. Потому что проблем с производительностью не будет. Разделяя код для каждой цели, вы реализуете разделение проблем (поправьте меня, если я ошибаюсь).

Если вы можете, инициализируйте клиентский код (соединение) только на тех страницах, где вы его фактически используете, разделив клиентский код SignalR (для каждого концентратора) в отдельный файл.

Возьмем мой последний пример: если у теста есть собственная страница, загружайте только клиентский код SignalR только на этой странице.


Еще одна вещь, которую вы можете попробовать, - это запросы AJAX. Иногда я разделяю свой код на разные контроллеры API и просто делаю запрос AJAX к своему контроллеру API, например, для обработки транзакций базы данных.

Вы также можете использовать некоторые функции SignalR внутри этого контроллера, используя _ 4_.

В ASP.NET Core SignalR вы можете получить доступ к экземпляру IHubContext через внедрение зависимостей. Вы можете внедрить экземпляр IHubContext в контроллер, промежуточное ПО или другую службу DI. Используйте экземпляр для отправки сообщений клиентам.

class SomeController : Controller
{
    private readonly IHubContext<MyHub> _hubContext;

    public SomeController(IHubContext<MyHub> hubContext)
    {
        _hubContext = hubContext;
    }
}

Документация по с использованием функций SignalR вне хаба, есть еще примеры.

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

person Matthijs    schedule 20.12.2018
comment
Because there will be no performance issues. Не совсем согласен. Каждый концентратор открывает свое собственное соединение, поэтому 100 пользователей сгенерируют 200 соединений вместо 100. Если использовались какие-то сеансы, их нужно было получить 200 раз, а не только 100 раз. Это также могло повлиять на батарею мобильных устройств, когда несколько соединений оставались открытыми. Я согласен на разделение проблем. Но я думаю, что здесь лучше старый подход: у вас есть четкое разделение между концентраторами, не беспокоясь о слишком большом количестве подключений. - person Lion; 05.09.2019
comment
Согласно этому сообщению, системы Apple, похоже, имеют ограничение в четыре соединения на сервер. Этого можно было бы легко достичь с помощью нескольких концентраторов в SignalR Core, но не было бы проблем при старом подходе с одним подключением. - person Lion; 05.09.2019

Как насчет использования частичных классов. Не уверен, есть ли у этого подхода обратная сторона.

    public partial class TestHub : Hub
    {

    }

    public  partial class TestHub {

    }


person David Blay    schedule 03.12.2019