Несколько концентраторов на одно соединение, чтобы предотвратить класс бога - PullRequest
Новая
       12

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

0 голосов
/ 20 декабря 2018

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

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

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

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

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

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

1 Ответ

0 голосов
/ 20 декабря 2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...