E>>Это значит, что нотификации должны быть объектами разных классов. E>>Либо содержать данные в виде объектов-данных разных типов. E>>Так как данные в нотификации могут быть разными в зависимости от типа операции. E>>Так?
S>Совершенно необязательно. У вас какая версия Windows? Если 10, то вы, наверное, заметили, что их notification center способен показывать оповещения о совершенно разных событиях — и об исчерпании места на диске, и о приходе почты, и вообще о чём угодно. Достаточно сделать так, чтобы внутри оповещения была сохранена "ссылка" на то действие, которое оно предлагает пользователю выполнить. S>Для отчёта, к примеру, основным действием будет "открыть окно отчёта", вместе с параметрами, которые указывают на конкретный экземпляр отчёта.
S>Это позволит вам избежать необходимости полностью переписывать ту часть клиента, которая отвечает за обработку оповещений, после добавления каждого типа оповещений.
Тут не согласен.
Вы говорите о нотификациях, которые отображаются конечному пользователю.
Мы же начинали разговор о "внутренних" нотификациях, которые создаются BL-слоем для UI-слоя.
UI слой должен, "прочитав" нотификации, понять какая каждая из этих нотификаций к какой инициированной им операции имеет отношение.
И отобразить результаты этих операций.
Пример.
Пользователь1 запустил асинхронные операции: загрузка на Кассу1, выгрузка на Кассу2.
Пользователь2 запустил асинхронные операции: выгрузка на Кассу3, загрузка на Кассу4.
В течении следующих 30 мин эти операции завершились, BL сформировал 7 нотификаций (допустим, что кроме этих 4 операций выполнялось еще каких-то 3 операции, и по ним тоже сформировались нотификации).
Как UI конкретного пользователя поймет какая из нотификаций имеет отношение к запущенной им операции?
По типу (классу) нотификации или по каким-то "универсальным" реквизитам нотификации?
E>>По всем книжкам BLL управляет слоем DAL. E>>BLL прямо "говорит" DAL: дай мне такие-то данные. E>>BLL не оповещает его, не события выкидывает, а дает прямые команды и инструкции DAL-у. E>>Ну конечно через интерфейс-адаптер, но это сути не меняет.
S>да нет такого, не знаю в каких ты это книжках прочитал, но бизнес слой это всегда чистая логика не знающая ни о чем и ни чем не управляющая
А какой же слой читает\записывает данные из БД при помощи DAL-слоя?
Здравствуйте, es3000, Вы писали: E>В общем согласен. E>Ну а если все-таки есть такое требование к программе: чтобы программа отображала пользователю окно с результатами выполнения асинхронной BL-операции, когда она завершается. E>Как это надо сделать?
Точно так же, как описано.
"Главное окно" по таймеру опрашивает метод "получить оповещения", обрабатывает его результаты. Например, для оповещния "отчёт готов" показывает окно с отчётом.
Пользователи будут вас проклинать, но чо уж там.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, es3000, Вы писали: E>Тоже согласен. E>Получается, надо нотификации привязывать к пользователю, роли или группе пользователей. E>Для простоты давайте рассмотрим случай, когда надо привязываться к пользователю. E>Получается, этот параметр надо передавать во все операции BL-слоя, и хранить в каждой нотификации. E>Правильно? Как это делается?
Да. E>Через параметры методов операций?
Конечно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 упадёт во время асинхронной операции, то после перезапуска информация о хэндлах исчезнет, и статус операции проверить будет нельзя.
Способ "по реквизитам" по крайней мере даёт нам возможность просмотреть пришедшие оповещения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, es3000, Вы писали:
E>Мы же начинали разговор о "внутренних" нотификациях, которые создаются BL-слоем для UI-слоя. E>UI слой должен, "прочитав" нотификации, понять какая каждая из этих нотификаций к какой инициированной им операции имеет отношение. E>И отобразить результаты этих операций.
E>Пример. E>Пользователь1 запустил асинхронные операции: загрузка на Кассу1, выгрузка на Кассу2. E>Пользователь2 запустил асинхронные операции: выгрузка на Кассу3, загрузка на Кассу4. E>В течении следующих 30 мин эти операции завершились, BL сформировал 7 нотификаций (допустим, что кроме этих 4 операций выполнялось еще каких-то 3 операции, и по ним тоже сформировались нотификации).
E>Как UI конкретного пользователя поймет какая из нотификаций имеет отношение к запущенной им операции? E>По типу (классу) нотификации или по каким-то "универсальным" реквизитам нотификации?
Каждый запрос нужно делать транзакционным с уникальным идентификатором.
