Блог

Я немного смущен правильным подходом или тем, какие решающие факторы следует учитывать при создании отдельных узлов или отдельных групп внутри узла.

В моем приложении есть 2 случая, когда вы используете pub sub:

1. Несколько пользователей имеют доступ к одним и тем же данным. Чтобы избежать переопределения изменений, внесенных одним пользователем другим, мы используем механизм блокировки, чтобы только 1 пользователь мог редактировать данные в данный момент. Pub sub уведомляет пользователей, заблокированы ли данные, которые они просматривают.
2. У нас есть какой-то длительный процесс создания отчетов, и мы используем pub sub для получения обновления состояния длительного процесса

В настоящее время у нас создан единый концентратор(«МОЙ-ПРИЛОЖЕНИЕ-КОНЦЕНТРАТОР») для всего приложения, и для обоих этих вариантов использования созданы отдельные группы «БЛОКИРОВКА ДАННЫХ-[ИДЕНТИФИКАТОР ДАННЫХ]-ГРУППА» и «ОТЧЕТ-[ИДЕНТИФИКАТОР ОТЧЕТА]-ГРУППА». Работает хорошо, никаких проблем нет.

Однако мне интересно, следует ли мне создавать отдельный КОНЦЕНТРАТОР для каждого действия, чтобы «ЗАБЛОКИРОВАТЬ КОНЦЕНТРАТОР ДАННЫХ» и «КОНЦЕНТРАТОР ОТЧЕТОВ», а затем создавать отдельные группы для каждого блока данных. Поэтому, например, в «LOCK-DATA-КОНЦЕНТРАТОРЕ» создайте группу «ДАННЫЕ-1-GRP», «ДАННЫЕ-2-GRP», аналогично «ОТЧЕТ-1-GRP», «ОТЧЕТ-2-GRP» для «ОТЧЕТА-КОНЦЕНТРАТОРА».

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

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