Я читал текст Уди Даана на тему [Разделение командного запроса и SOA] [1]. Думая о том, как бы я использовал это на практике в системе, над которой я сейчас работаю, возникли некоторые вопросы ...
1
Рассмотрим следующую ситуацию, когда у меня есть клиентское приложение WPF, которое позволяет пользователю редактировать список записей:
Клиентское приложение запущено. При запуске он подписывается на службу команд, которая будет обрабатывать и публиковать изменения в записях, и запрашивает у службы WCF полный список записей. После получения списка записей любые изменения (другими клиентами), которые могли быть опубликованы в очереди клиентов, пока она была занята ожиданием ответа от WCF, объединяются в список.
Теперь мне кажется, что есть (вероятно, очень маленький) шанс, что клиент подпишется сразу после обработки команды, ответственной за изменение, и что запрос службы WCS запускается непосредственно перед тем, как то же самое изменение было зафиксировано в базе данных. , В этой ситуации я в конечном итоге с неправильными данными в моем клиенте, который не является (и никогда не попасть в) синхронизации с базой данных (если клиентское приложение не будет перезапущен). Действительно ли существует эта проблема, и если она существует, как ее следует решать?
2.
Мой второй вопрос о том, как спроектировать / реализовать пользовательский интерфейс:
Теперь пользователь хочет изменить запись в списке; Появляется окно, данные изменяются и нажимается кнопка «ОК»: мы отправляем сообщение в наш обработчик команд, чтобы обработать это изменение.
Пользователь ожидает увидеть либо подтверждение (запись в списке изменится), либо ошибку
сообщение.
Теперь я могу попытаться обрабатывать вещи в пользовательском интерфейсе «синхронно» (пусть пользователь делает одну вещь за раз, и пусть он ждет успеха или неудачи, прежде чем ему позволят делать что-то еще) следующим образом :
- После того, как пользователь нажмет ok, отключите все элементы управления, чтобы дальнейшее редактирование было невозможно.
- Создать сагу с таймаутом, который ждет ...? Ответное сообщение? Опубликованное уведомление от командного сервиса? И то и другое?
- Когда сообщение будет получен ответ данные в списке изменяется, элементы управления включены и мы сделали - или:
- Тайм-аут происходит. Командное сообщение было поставлено в очередь, поэтому изменение в конечном итоге будет выполнено, что делать? Показать сообщение пользователю («это занимает больше времени, чем ожидалось ...»), включить все элементы управления и изменить данные на клиенте после получения уведомления от службы команд? Но что, если ошибка возвращается? Пользователь, возможно, начал делать что-то другое (возможно редактированием другой записи) и выскакивает сообщение об ошибке от предыдущего редактирования попытки не кажется хорошей идея.
Другой подход, вероятно, состоит в том, чтобы просто отправить команду и позволить пользователю продолжить то, что ему нравится делать дальше. Может быть, показать все выдающиеся команды в списке в пользовательском интерфейсе где-нибудь, с индикатором успеха или сбоя и возможностью для пользователя отображать сообщение об ошибке в случае сбоя. Учитывая, что тайм-ауты, как мы надеемся, являются исключительными, и что ответы, как правило, должны быть получены в течение нескольких секунд, это будет означать, что в этом списке обычно должно быть не более 1 невыполненной команды. Это и тот факт, что я не могу вспомнить, что я когда-либо видел пользовательский интерфейс, выполняющий такие действия, означает, что это, вероятно, не очень хорошая идея.
А твой вопрос? ;)
Ну, мне просто интересно, как другие люди решают это в своих пользовательских интерфейсах. Вероятно, есть более эффективные способы обработки вещей в пользовательском интерфейсе, чем два, может быть, не очень умных, которые я придумал?
Извиняюсь за длинный текст и заранее благодарю за ваши ответы.
[1]: http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/"Command Разделение запросов и SOA "