Re[8]: Бизнес-слой управляет другим слоем
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.06.19 03:34
Оценка:
Здравствуйте, es3000, Вы писали:
E>Пример.
E>Пользователь1 запустил асинхронные операции: загрузка на Кассу1, выгрузка на Кассу2.
E>Пользователь2 запустил асинхронные операции: выгрузка на Кассу3, загрузка на Кассу4.
E>В течении следующих 30 мин эти операции завершились, BL сформировал 7 нотификаций (допустим, что кроме этих 4 операций выполнялось еще каких-то 3 операции, и по ним тоже сформировались нотификации).

E>Как UI конкретного пользователя поймет какая из нотификаций имеет отношение к запущенной им операции?

Я не вполне понимаю, что значит "поймёт". Например, UI легко получает список нотификаций, привязанных к текущему пользователю.
E>По типу (классу) нотификации или по каким-то "универсальным" реквизитам нотификации?
Ну, очевидно, что по классу мы ничего не получим — параллельно может выполняться много операций одного класса.
Есть два способа, которым UI может привязывать нотификацию к инициированной им операции.
Один — по реквизитам. То есть где-то в UI мы заводим список ожидания, в котором, скажем, в момент запуска операции "загрузка на Кассу 1" появляется запись "ждём оповещения об окончании загрузки на Кассу 1". UI при выгребании списка оповещений сравнивает их с теми, что в листе ожидания, и при совпадении активирует заранее заготовленную логику.
Второй — по хэндлу. То есть все асинхронные операции в BL возвращают некоторый handle, по которому потом можно дёрнуть метод GetAsyncOperationStatus.
Этот способ менее надёжен, потому что если UI упадёт во время асинхронной операции, то после перезапуска информация о хэндлах исчезнет, и статус операции проверить будет нельзя.
Способ "по реквизитам" по крайней мере даёт нам возможность просмотреть пришедшие оповещения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.