Здравствуйте, es3000, Вы писали:

E>1) Этот код — запрос на дальнейшую обработку файла — это часть логики приложения.
E>Это не часть UI.
E>Получается, что важный для логики работы код находится вне бизнес-слоя, в каком-то другом слое.
E>Мне кажется это не хорошо.

"запрос на дальнейшую обработка файла" не является бизнес логикой. Если файл не может быть сохранен — то сервис ловит исключение и обрабатывает его должным образом (показывая пользователю окно, где он либо должен ввeсти новое имя, либо изменить какие-то настройки, например разрешить перезаписать файл поверх существующего)

E>2) На всех схемах дизайна приложения слой "Сервис" рисуется подчиненным по отношению к UI.
E>То есть согласно этим схемам не "Сервис" управляет пользовательским интерфейсом, а пользовательский интерфейс управляет "Сервисом".
E>Ты же предлагаешь сделать наоборот.
E>Тогда, наш "Сервис" будет супер-главным слоем, а все остальные ему подчинены.
E>Нету тут противоречия?

При стандартном подходе UI ответственна только за рисование пикселей и отображение окон. Не знаю читал-ли ты эти паттерны, но там есть несколько вариантов, "тупой" UI — он вообще ничего ни о чем не знает и им управляет контроллер или сервис, контроллер знает о бизнес обьектах, вызывает их методы и соответственно командует интерфейсом для обновления данных и показе новых окон. "Немного более умный" UI завязывается на события и свойства бизнес-обьектов и сам отображает нужные данные при смене состояния бизнес обьектов, есть еще пара разновидностей типа mvvc уже не помню его точных отличий. Но виндовая разработка уже в прошлом, сейчас в моде веб, api, spa, микросервисы и прочее, я-б на твоем месте уделял им внимание т.к. будущее за ними, а не за тем кто и как управляет отображением очередной виндовой формы

S>"запрос на дальнейшую обработка файла" не является бизнес логикой.

Почему?
Может же быть такое приложение, которое работает с файлами.
Допустим мы пишем новый файловый менеджер — для него предметной областью является работа с файлами.
Получается, мы искусственно "вырезаем" логику из слоя BLL и переносим куда-то.

S>При стандартном подходе UI ответственна только за рисование пикселей и отображение окон.
S>... контроллер знает о бизнес обьектах, вызывает их методы и соответственно командует интерфейсом для обновления данных и показе новых окон.

Получается, все контроллеры в совокупности и есть этот "Сервис"-слой?

Здравствуйте, es3000, Вы писали:

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

public BoardState HandleUserMove(BoardState currentState, Move userMove)

То есть мы передаём состояние доски и свой ход. "Бизнес логика" проверяет, что предложенный ход корректен, и выкинет исключение, если что-то не так.
В состояние доски, помимо расположения фигур, входит также набор уже срубленных фигур, и история ходов обеих сторон.
Это позволяет нам обойтись полностью Stateless реализацией, что имеет массу очевидных преимуществ.

UI при этом может быть совершенно произвольным — графическим, текстовым, 3d с анимациями, да хоть почтовым роботом.
Мы получаем от BL описание нового состояния доски, и "рисуем" именно его. Всё.
Это — основа, на которую можно наворачивать дополнительную логику.
Если мы вдруг хотим улучшить удобство интерфейса и подготовиться к экзотической ситуации "правила шахмат могут внезапно меняться", то можно добавить метод GetValidMoves(BoardState currentState) (Вряд ли нам потребуется более мелкая гранулярность, т.к. количество возможных ходов всеми фигурами для любого состояния доски едва ли превышает несколько сотен).
Впрочем, как product manager я бы зарубил реализацию этого метода в BL вплоть до получения внятного обоснования. Полезность этого метода слишком зависит от специфики UI, поэтому для начала я бы предложил реализовать его именно на стороне UI. Вот если у нас окажется больше одной параллельной реализации UI, которым нужен такой метод, при этом переиспользование кода традиционным путём невозможно, то можно будет задуматься о расширении BL.

Если у нас есть желание предотвратить "жульничество" пользователем, который подсовывает рукодельную историю ходов и положение доски, то всегда можно добавить в BoardState цифровую подпись сервера.
И, скажем, постановка мата нашему сервису будет заслуживать приза только если currentState подписан корректно. А если не подписан — то это просто кто-то играет с нами этюд.

Здравствуйте, es3000, Вы писали:
E>Решение отображения уведомления в UI при поступлении почты.
E>Мне интересно как это правильно сделать по твоему мнению.
E>Какие действия при этом выполняются и какими объектами\слоями?
Слой UI по таймеру дёргает метод BL ReceiveNotificationsSince(lastProcessedMarker)
А дальше — по своему усмотрению: всплывающая плашка в трее, кружочек с количеством непрочитанных нотификаций над иконкой "почта", воспроизведение звука/цвета/запаха...

Q>Вводить исходные данные для расчета з/п могут несколько человек в течении нескольких дней, у каждого свой UI в определенном состоянии, который они закрывают в конце рабочего дня.
Q>Т.е. состояние объектов бизнес-логики пассивно по отношению к UI.

А почему бизнес-логика не может повести себя активно?
Например, при запуске программы на следующий день, инициализируется бизнес-логика.
Бизнес-логика видит, что для завершения расчета зарплаты нужна следующая порция данных, и дает сигнал.
А UI реагирует на этот сигнал и выводит красивое уведомление "Для завершения расчета зарплаты надо ввести данные такие-то".

Q>Когда в UI открыли какой-то диалог, ввели данные и нажали ОК, то изменяется состояние объектов бизнес-логики (и состояние БД, в конечном счете).
Q>Если происходит нарушение условий бизнес-логики, то генерируется ошибка.
Q>Чтобы UI-диалог не закрывался при заведомо ошибочных условиях, у модуля бизнес-логики должен быть API валидации данных.
Q>Бизнес-логика не завязана на действия пользователя. Бизнес-логика проверяет входящие запросы и генерирует ошибку, если запросы противоречат ее внутренним правилам.
Q>Пользователь делает, что хочет, но если это противоречит правилам бизнес логики, то получает ошибку.

Это все понятно. Это стандартное "книжное" взаимодействие UI и BLL.

Я просто веду разговор к тому, что есть масса задач, где именно BLL должна инициировать какие-то действия.

E>>То есть бизнес-логика управляет пользовательским интерфейсом.
Q>Нет. Бизнес-логика прекрасно живет без всякого UI, ей не важно кто дергает API.

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

Анализ текущей даты и даты сдачи отчетности — это не дело UI.
Значит, этот анализ надо поместить в BLL.
И "заставить" UI нарисовать это окошко.
А если UI не нарисует — значит это плохой UI, его надо переделать.

Q>Разработчик для создания дружественного пользователю UI может предусмотреть дополнительное API для подсказок по control flow и валидации данных.

Вот может быть такие "подсказки" будут решением.
Как реализуются такие подсказки по control flow?

E>Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?

Длинное получилось обсуждение.
Есть еще два вопроса, которые связаны с исходным вопросом.
Задам каждый в отдельной ветке, чтобы удобнее было осуждать.

Первый вопрос.

BLL при изменении своего состояния оповещает вышестоящие слои.
Какой механизм оповещений используется? Что-то типа подписок на события.
Типа "финансовый отчет готов".
Обработчик события — это обычная функция.

В чем разница между вызовом обработчика события, который дергает подписчиков, и прямой передачи какой-то команды?
Ведь передача команды — это такая же функция.
Почему нельзя вместо события вызвать функцию вышестоящего слоя "Забирай отчет и покажи его"?

E>Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?

Еще вопрос.

По всем книжкам BLL управляет слоем DAL.
BLL прямо "говорит" DAL: дай мне такие-то данные.
BLL не оповещает его, не события выкидывает, а дает прямые команды и инструкции DAL-у.
Ну конечно через интерфейс-адаптер, но это сути не меняет.

Более того.
Если оказывается, что бизнес-данные лежат например в разных СУБД, то бизнес-слой будет запрашивать данные уже у двух разных DAL.

То есть BLL может и должен управлять другими слоями, если ему это надо для решения своей задачи.

Почему же BLL не может отправить такую же команду запроса данных у другого слоя, отличного от DAL?
Также через интерфейс-адаптер.

Вот в чем вопрос.
Может ли BLL запрашивать данные у других слоев, а не только у DAL?
Если нет — то почему?

Здравствуйте, es3000, Вы писали:

E>А почему бизнес-логика не может повести себя активно?
E>Например, при запуске программы на следующий день, инициализируется бизнес-логика.
E>Бизнес-логика видит, что для завершения расчета зарплаты нужна следующая порция данных, и дает сигнал.
E>А UI реагирует на этот сигнал и выводит красивое уведомление "Для завершения расчета зарплаты надо ввести данные такие-то".

При минимальном масштабировании из простой однопользовательской локальной программы в простейший клиент-сервер такой подход развалится.
Конечно, если есть желание в 2019 году разрабатывать софт в духе Turbo Pascal для MS DOS, то можно и активную бизнес логику сделать.

В масштабируемой архитектуре бизнес-логика живет на сервере (или серверах — для распределенных систем).
При этом никто не мешает элементарно сделать напоминашки при запуски какого-то клиентского приложения.
Т.е. при запуске или по таймеру UI может спросить у сервера текущее состояние объектов бизнес логики и послать пользователя в налоговую или еще куда-нибудь.

Здравствуйте, es3000, Вы писали:

E>Почему?
E>Может же быть такое приложение, которое работает с файлами.
E>Допустим мы пишем новый файловый менеджер — для него предметной областью является работа с файлами.
E>Получается, мы искусственно "вырезаем" логику из слоя BLL и переносим куда-то.

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

E>Получается, все контроллеры в совокупности и есть этот "Сервис"-слой?

для виндовых толстых клиентов — да

Здравствуйте, es3000, Вы писали:

E>По всем книжкам BLL управляет слоем DAL.
E>BLL прямо "говорит" DAL: дай мне такие-то данные.
E>BLL не оповещает его, не события выкидывает, а дает прямые команды и инструкции DAL-у.
E>Ну конечно через интерфейс-адаптер, но это сути не меняет.

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

Здравствуйте, es3000, Вы писали:

E>А почему бизнес-логика не может повести себя активно?
E>Например, при запуске программы на следующий день, инициализируется бизнес-логика.
E>Бизнес-логика видит, что для завершения расчета зарплаты нужна следующая порция данных, и дает сигнал.
E>А UI реагирует на этот сигнал и выводит красивое уведомление "Для завершения расчета зарплаты надо ввести данные такие-то".
Ну, откуда же здесь "активность"? Пока программу не запустили, бизнес-логика позорно спала.
А если бизнес-логика начинает "активничать" только при запуске программы, то в ней активности не больше, чем в дверном звонке: пока не нажмёшь на кнопку, он не звонит.

В нормальной архитектуре программа при запуске (и не только при запуске) дёргает метод BL GetNotifications(...), который выдаёт ей все оповещения.
У этого подхода — масса преимуществ. Например, что будет делать ваша программа, когда "красивое оповещение" захотят показать сразу два модуля — зарплата и налоги?
Получается, каждый из них должен учитывать не только свои хотелки, но и то, что параллельно могут работать другие модули.
В классической архитектуре именно UI решает, как с этим быть. То ли показать модальные диалоги в foreach(); то ли показать окно со списком оповещений; то ли вывести плашку с оповещениями и кнопками "вперёд"/"назад" в главном окне.
А может быть это вообще не UI, а сервис, который запускается по расписанию, и превращает каждое оповещение в email/SMS, который отправляется пользователю.
Бизнес-логика ничего этого не знает, её не нужно переписывать для того, чтобы научить работать в каждом из этих сценариев. Ей не нужно отслеживать, получил ли пользователь эти уведомления, или нет.

E>Я просто веду разговор к тому, что есть масса задач, где именно BLL должна инициировать какие-то действия.
Нет таких задач.

E>Ну а вот такой пример. Допустим имеем приложение для индивидуального предпринимателя.
E>Он запускает программу в последний день сдачи декларации.
E>Нужно, чтобы программа при запуске ему вежливо и красиво нарисовала окошко "Дорогой предприниматель! Беги скорее в налоговую, сегодня последний день!".
E>Анализ текущей даты и даты сдачи отчетности — это не дело UI.
E>Значит, этот анализ надо поместить в BLL.
См. выше.
E>И "заставить" UI нарисовать это окошко.
E>А если UI не нарисует — значит это плохой UI, его надо переделать.
"Заставление" UI можно делать десятком способов. Вхреначивать их в BL — максимально плохая идея.

Здравствуйте, es3000, Вы писали:

E>BLL при изменении своего состояния оповещает вышестоящие слои.
E>Какой механизм оповещений используется? Что-то типа подписок на события.
E>Типа "финансовый отчет готов".
E>Обработчик события — это обычная функция.

E>В чем разница между вызовом обработчика события, который дергает подписчиков, и прямой передачи какой-то команды?
E>Ведь передача команды — это такая же функция.
E>Почему нельзя вместо события вызвать функцию вышестоящего слоя "Забирай отчет и покажи его"?
Во-первых, потому, что у одного события может быть одновременно несколько обработчиков.
Во-вторых, потому, что вышестоящий слой может не хотеть "забирать и показывать" отчёт вот прямо вот сейчас. Например, пользователь сейчас выступает с презентацией перед потенциальным партнёром, и тут ваш мерзкий вышестоящий слой ХОБА! и показал "отчёт об убытках за 2 квартал", полностью опровергающий презентацию. Событие — это "вот что произошло", ReportReady. А "функция" — это "вот что я хочу сделать", это ShowReport().

В-третьих, оба решения плохи. Потому что в обоих BLL требует, чтобы рядом был вышестоящий слой, причём с очень конкретными возможностями. Если вышестоящий слой по какой-то причине недоступен — всё, копец, сломалась бизнес-логика. Отчёт, который строился 40 часов, не удалось показать пользователю, потому что в это время уже был запущен модальный диалог. Всё, упс, запускаем отчёт заново. Или реализация перевода денег со счёта на счёт перед коммитом решила дёрнуть событие BeforeTransferComplete, а UI-программист влепил в OnBeforeTransferComplete модальный message box. Пользователь кнопочку submit нажал, вышел покурить, да так и ушёл на выходные. Диалог висит, управление в BLL так и не вернулось, транзакция открыта, поступление денег на оба счёта заблокировано в ожидании окончания транзакции.
Оттого что в кузнице не было гвоздя. Не надо так делать. BLL всегда должна быть пассивной. Хочется поделиться чем-то с пользователем — есть стандартный паттерн:
1. Есть общий для всех BLL-модуль "оповещения о событиях".
2. Каждый модуль может пользоваться SubmitNotification, который записывает оповещения в очередь.
3. Степень развесистости этого модуля бывает различной. От примитивных текстовых сообщений, до структур с ShortDescription, FullDescription, Stage(Begin/Progres/Complete), Status(Info/Error/Warning), ProposedAction, и вложенностью нотификаций.
4. Те клиенты UI, которые хотят работать с нотификациями, пишут свою реализацию опроса нотификаций поверх конкретно этого модуля. Это позволяет написать клиента (или как минимум эту его часть) один раз, и не приделывать ему новые функции всякий раз, как BLL хочет сообщить о чём-то новом (готовность отчёта, необходимость рассчитать зарплату, запрос от налоговой и т.п.).
5. Эта реализация может приоритизировать нотификации, помечать статусы прочитанности, и так далее. А может и ничего не делать — к примеру, просто форвардить нотификации в почту, WhatsApp, SMS, и.т.п. При этом BLL не надо переписывать каждый раз при добавлении нового канала отправки, и она не встаёт колом при каждой потере связи с сервисом WhatsApp.

Вот это — нормальный способ реализовать "финансовый отчёт готов".

E>>Бизнес-логика видит, что для завершения расчета зарплаты нужна следующая порция данных, и дает сигнал.
E>>А UI реагирует на этот сигнал и выводит красивое уведомление "Для завершения расчета зарплаты надо ввести данные такие-то".

S>Ну, откуда же здесь "активность"? Пока программу не запустили, бизнес-логика позорно спала.
S>А если бизнес-логика начинает "активничать" только при запуске программы, то в ней активности не больше, чем в дверном звонке: пока не нажмёшь на кнопку, он не звонит.

S>В нормальной архитектуре программа при запуске (и не только при запуске) дёргает метод BL GetNotifications(...), который выдаёт ей все оповещения.

Но все-таки уведомления должен вычислить именно бизнес-слой.
Правильно?
А их обработку — UI.

E>>И "заставить" UI нарисовать это окошко.
E>>А если UI не нарисует — значит это плохой UI, его надо переделать.
S>"Заставление" UI можно делать десятком способов.

Можете привести примеры?
Например, какие три самых "лучших" способа с точки зрения правильного проектирования?

E>>В чем разница между вызовом обработчика события, который дергает подписчиков, и прямой передачи какой-то команды?
E>>Ведь передача команды — это такая же функция.
E>>Почему нельзя вместо события вызвать функцию вышестоящего слоя "Забирай отчет и покажи его"?

S>Во-первых, потому, что у одного события может быть одновременно несколько обработчиков.

Ну и функцию можно также реализовать.

S>Во-вторых, потому, что вышестоящий слой может не хотеть "забирать и показывать" отчёт вот прямо вот сейчас.
S>Событие — это "вот что произошло", ReportReady. А "функция" — это "вот что я хочу сделать", это ShowReport().

Это назначение метода мы же сами придумываем.
Технически это одно и тоже.

Кроме того, функция может быть асинхронной.
Она может сразу ничего не вернуть. А потом спустя какое-то время вызвать метод BLL.ShowReportFinished()

Все-таки разница не очень понятна.

S>Хочется поделиться чем-то с пользователем — есть стандартный паттерн:
S>1. Есть общий для всех BLL-модуль "оповещения о событиях".
S>2. Каждый модуль может пользоваться SubmitNotification, который записывает оповещения в очередь.
S>4. ... клиенты ... пишут свою реализацию опроса нотификаций поверх конкретно этого модуля.

А чем этот способ отличается от подписки на события?

S>Вот это — нормальный способ реализовать "финансовый отчёт готов".

Как в этом случае, UI найдет среди все очереди нотификаций именно эту — "финансовый отчёт готов"?
Значит, надо вводить какие-то признаки типа NotificationType?

А если например параллельно в BL выполняется расчет двух финансовых отчетов.
В очереди 10 нотификаций.
Как понять какая нотификация к первому отчету, а какая ко второму?

Здравствуйте, es3000, Вы писали:
E>Но все-таки уведомления должен вычислить именно бизнес-слой.
E>Правильно?
В данном варианте — да.
E>А их обработку — UI.
Совершенно необязательно. Может и никто не делать. Никакой зависимости поведения бизнес-логики от того, получено ли уведомление, быть не должно.

E>>>И "заставить" UI нарисовать это окошко.
E>>>А если UI не нарисует — значит это плохой UI, его надо переделать.
S>>"Заставление" UI можно делать десятком способов.
E>Можете привести примеры?
E>Например, какие три самых "лучших" способа с точки зрения правильного проектирования?
Я давал подробную инструкцию по работе с уведомлениями в параллельных ветках.

Здравствуйте, es3000, Вы писали:

S>>Во-первых, потому, что у одного события может быть одновременно несколько обработчиков.
E>Ну и функцию можно также реализовать.
Нет, для этого "функция" должна знать обо всех потребителях оповещения. А стандартные события дотнета сделаны так, чтобы каждый обработчик знал только о событии; ему всё равно, сколько ещё есть обработчиков.
Это упрощает тестирование, т.к. каждого из обработчиков можно тестировать независимо.
Но при наивной реализации подписка на события всё ещё плоха — потому что один "сломанный" обработчик может заклинить всех остальных.

S>>Во-вторых, потому, что вышестоящий слой может не хотеть "забирать и показывать" отчёт вот прямо вот сейчас.
S>>Событие — это "вот что произошло", ReportReady. А "функция" — это "вот что я хочу сделать", это ShowReport().

E>Это назначение метода мы же сами придумываем.
E>Технически это одно и тоже.
Забудьте про технику. Внутри процессора вообще нет ни методов, ни событий, ни имён функций. Технически все программы эквивалентны машине Тьюринга.
Архитектура — она про семантику.

E>Кроме того, функция может быть асинхронной.
E>Она может сразу ничего не вернуть. А потом спустя какое-то время вызвать метод BLL.ShowReportFinished()
Отлично. Вы только что увеличили стоимость разработки ещё втрое. Без малейшего увеличения полезности.

E>А чем этот способ отличается от подписки на события?
Тем, что модуль, порождающий оповещения, ни формально ни фактически не зависит от их потребителей.
Даже если никто не обрабатывает оповещения — ничего не сломается. Если клиент сломался в процессе доставки оповещения — при перезапуске он сможет показать его снова.
UI может вообще отсутствовать в момент порождения оповещения — в понедельник пользователь придёт в офис, запустит программу, и получит все оповещения, сгенерированные за выходные.
E>Как в этом случае, UI найдет среди все очереди нотификаций именно эту — "финансовый отчёт готов"?
А зачем ему искать "именно эту"?
Ваш почтовый клиент ищет среди всех писем именно то, которое из банка? Или просто показывает "в инбоксе 180 непрочитанных писем"?
E>Значит, надо вводить какие-то признаки типа NotificationType?
Зачем?
E>А если например параллельно в BL выполняется расчет двух финансовых отчетов.
E>В очереди 10 нотификаций.
E>Как понять какая нотификация к первому отчету, а какая ко второму?
Наверное, из содержимого нотификации. А вы как думаете?

E>>Как в этом случае, UI найдет среди все очереди нотификаций именно эту — "финансовый отчёт готов"?

S>А зачем ему искать "именно эту"?
S>Ваш почтовый клиент ищет среди всех писем именно то, которое из банка? Или просто показывает "в инбоксе 180 непрочитанных писем"?

Пример почтового клиента не подходит.
Почтовый клиент просто принимает письма. Он не выполянет никаких специфических действий.

Я же спрашиваю про такую ситуацию, когда UI инициировал некоторую асинхронную операцию в BL.
И по окончании этой операции должен показать ее результат.
Мы говорили, что когда BL закончит операцию, он сформирует нотификацию.
Но, поскольку операции в BL выполняются асинхронно, например, разными клиентами с разных ПК, то в BL будет много нотификаций в очереди.
Как конкретный клиент найдет именно свою нотификацию о той операции, которую он инициировал?


E>>А если например параллельно в BL выполняется расчет двух финансовых отчетов.
E>>В очереди 10 нотификаций.
E>>Как понять какая нотификация к первому отчету, а какая ко второму?

S>Наверное, из содержимого нотификации. А вы как думаете?

Это значит, что нотификации должны быть объектами разных классов.
Либо содержать данные в виде объектов-данных разных типов.
Так как данные в нотификации могут быть разными в зависимости от типа операции.
Так?

Здравствуйте, es3000, Вы писали:

E>Пример почтового клиента не подходит.
E>Почтовый клиент просто принимает письма. Он не выполянет никаких специфических действий.
И это — правильно.

E>Я же спрашиваю про такую ситуацию, когда UI инициировал некоторую асинхронную операцию в BL.
E>И по окончании этой операции должен показать ее результат.
Ну, во-первых, ничего он не должен. Главный тут нe BL и не UI, а пользователь.
Я же вам приводил уже пример — возможно, пользователь сейчас показывает презентацию на большом экране. UI, который вдруг решает "показать результат асинхронной операции" тут нафиг не нужен.
Логичным является сделать специальный раздел в UI, что-то типа "история операций", где видно, какая операция когда была запрошена, каков её прогресс (если известно), когда ожидается завершение (если известно).
Если статус — "готово", то с оповещением могут быть связаны результаты, которые можно увидеть, кликнув по ним.

E>Мы говорили, что когда BL закончит операцию, он сформирует нотификацию.
E>Но, поскольку операции в BL выполняются асинхронно, например, разными клиентами с разных ПК, то в BL будет много нотификаций в очереди.
E>Как конкретный клиент найдет именно свою нотификацию о той операции, которую он инициировал?
Смотря как вы это спроектируете. Посмотрите на это под другим углом: важно не "какой клиент инициировал операцию", а кто заинтересован в результате.
В простом случае у нас есть личность пользователя. Тогда каждый клиент должен выгребать оповещения обо всех операциях, инициированных текущим пользователем. Независимо, естественно, от того, через какого клиента был выполнен запрос. То есть я могу заказать отчёт с мобильного телефона, а потом сесть за десктоп, и получить оповещение о готовности отчёта.
В более сложном случае у каждого оповещения есть группа заинтересованных пользователей. Например, "готовность квартального отчёта" получает все пользователи с ролью "бухгалтерия".
"исчерпание свободного места в разделе для временных данных" получают все с ролью "администрирование IT ресурсов".

S>>Наверное, из содержимого нотификации. А вы как думаете?

E>Это значит, что нотификации должны быть объектами разных классов.
E>Либо содержать данные в виде объектов-данных разных типов.
E>Так как данные в нотификации могут быть разными в зависимости от типа операции.
E>Так?
Совершенно необязательно. У вас какая версия Windows? Если 10, то вы, наверное, заметили, что их notification center способен показывать оповещения о совершенно разных событиях — и об исчерпании места на диске, и о приходе почты, и вообще о чём угодно. Достаточно сделать так, чтобы внутри оповещения была сохранена "ссылка" на то действие, которое оно предлагает пользователю выполнить.
Для отчёта, к примеру, основным действием будет "открыть окно отчёта", вместе с параметрами, которые указывают на конкретный экземпляр отчёта.

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

E>>Я же спрашиваю про такую ситуацию, когда UI инициировал некоторую асинхронную операцию в BL.
E>>И по окончании этой операции должен показать ее результат.

S>Ну, во-первых, ничего он не должен. Главный тут нe BL и не UI, а пользователь.
S>Я же вам приводил уже пример — возможно, пользователь сейчас показывает презентацию на большом экране. UI, который вдруг решает "показать результат асинхронной операции" тут нафиг не нужен.
S>Логичным является сделать специальный раздел в UI, что-то типа "история операций", где видно, какая операция когда была запрошена, каков её прогресс (если известно), когда ожидается завершение (если известно).
S>Если статус — "готово", то с оповещением могут быть связаны результаты, которые можно увидеть, кликнув по ним.

В общем согласен.
Ну а если все-таки есть такое требование к программе: чтобы программа отображала пользователю окно с результатами выполнения асинхронной BL-операции, когда она завершается.
Как это надо сделать?

E>>... когда BL закончит операцию, он сформирует нотификацию.
E>>Но, поскольку операции в BL выполняются асинхронно, например, разными клиентами с разных ПК, то в BL будет много нотификаций в очереди.
E>>Как конкретный клиент найдет именно свою нотификацию о той операции, которую он инициировал?

S>Смотря как вы это спроектируете. Посмотрите на это под другим углом: важно не "какой клиент инициировал операцию", а кто заинтересован в результате.
S>В простом случае у нас есть личность пользователя. Тогда каждый клиент должен выгребать оповещения обо всех операциях, инициированных текущим пользователем.

Тоже согласен.
Получается, надо нотификации привязывать к пользователю, роли или группе пользователей.
Для простоты давайте рассмотрим случай, когда надо привязываться к пользователю.
Получается, этот параметр надо передавать во все операции BL-слоя, и хранить в каждой нотификации.
Правильно? Как это делается?
Через параметры методов операций?