ZlobnyZerg Ответов: 1

Что является лучшим способом для обработки в WCF обратного вызова в многооконном клиента?

Всем привет. В настоящее время я разрабатываю клиент - серверное приложение с использованием WCF (duplex). Достаточно ясно, как обрабатывать обратные вызовы в простом клиенте. Но мой клиент должен быть сложным многооконным приложением. На данный момент я реализую ICallback в главном окне. Поэтому во всех дочерних окнах я создаю метод, который вызываю внутри методов обратного вызова для передачи данных дочернему объекту. Этот путь кажется мне отвратительным. Особенно для детей 3-го или 4-го уровня. Поэтому я хочу узнать, существует ли "лучшая практика" или что-то в этом роде для обработки обратных вызовов многими окнами. Может быть, это и глупый вопрос, но я действительно не могу найти ответа.

Что я уже пробовал:

Я пытаюсь "погуглить" его, но не получаю достаточно близкого результата.

1 Ответов

Рейтинг:
12

PureNsanity

У меня есть ответ, но у меня также есть альтернативная рекомендация для обратных вызовов WCF...

Передача данных по всему приложению должна осуществляться через службы (в смысле DDD) и шину. Таким образом, произойдет следующее: сервисный объект, вызывающий службу WCF, получит информацию об обратном вызове, а затем отправит соответствующее сообщение/объект по шине. Любой другой объект в приложении, желающий получить информацию, затем просто подпишется на шину.

Для простого применения шины вы можете использовать реактивный предмет. PRISM содержит EventAggregator, который также может быть использован; однако я лично настоятельно не рекомендую его использовать. Реактивные объекты в целом гораздо мощнее и с ними легче работать.

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

Мировой шинной архитектуре в C#[^]

Структура Единой Шины Сообщений - Часть 1[^]

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

Допустим, например, у меня есть корпоративное приложение, и я обновляю пользователя. Разве их, вероятно, не другие приложения, которые будут нуждаться в этой обновленной информации? Как он попадет в другие приложения, если вызов службы WCF является локальным для приложения? Ну, не может быть... Вам придется создать совершенно отдельную службу для опроса репозитория, чтобы узнать, произошло ли обновление. Это не только громоздко, но и в зависимости от того, сколько приложений требуют этой информации, это может ухудшить производительность.

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

По общему признанию, это большая корректировка, но эй... По крайней мере, в статьях я предоставляю целую структуру, уже построенную для обработки этого!