Рекомендации GUI для возможной согласованности?

Question

При использовании распределенной и масштабируемой архитектуры конечная согласованность часто является требованием.

Графически, как справиться с этой возможной согласованностью?

Пользователи используют нажатие кнопки «Сохранить» и видят результатмгновенно ... с возможной согласованностью это невозможно.

Как работать с графическим интерфейсом для таких сценариев?

Обратите внимание, что вопрос относится как к настольным приложениям, так и к веб-приложениям.

PS: я работаю с платформой Microsoft, но я думаю, что вопрос относится к любой технологии ...

Answer 1

A Task Based UI отлично подходит для этой модели. Вы создаете и выполняете задачи из пользовательского интерфейса. Вы также можете иметь что-то вроде монитора состояния задачи, чтобы показать пользователю, когда задача выполнена.

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

Другой (хороший?) Вариант - принимать / разрабатывать команды, которые не дают ошибок. Это не тривиально, но вы можете иметь кеш на клиенте и добавлять данные из команды в этот кеш и отображать их пользователю даже до того, как команда будет выполнена. Если команда завершилась неудачно в какой-то неожиданной ситуации, тогда просто создайте хорошее сообщение «извините», чтобы ввести пользователя в заблуждение на несколько секунд.

Вы также можете комбинировать методы выше.

Обычно возможная согласованность - это скорее проблема бизнеса / домена, и ваши эксперты по доменам должны ее решить.

Answer 2

Есть 2 способа:

1. Чтобы обмануть пользователя (просто чтобы показать, что что-то произошло, тогда они на самом деле еще не произошло)
2. Показать, что система обрабатывает запрос и использовать опрос в фоновом режиме (не хорошо) или просто таймер со значением ваш SLA.

Я предпочитаю 1-й вариант.

Answer 3

Я думаю, что другие ответы смешивают CQRS в целом и возможную согласованность в частности. Пользовательский интерфейс на основе задач очень подходит для CQRS, но он не решает проблему с согласованной моделью чтения.

Во-первых, я хотел бы оспорить ваше утверждение:

Пользователи нажимают кнопку «Сохранить» и мгновенно видят результат ... с возможной последовательностью это невозможно.

Что ты этим считаешь? Почему невозможно сразу увидеть результат ? Я думаю, что проблема здесь в вашем определении результата .

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

• Отправка электронного письма: если пользователь ввел правильный адрес электронной почты, почти гарантировано, что действие будет успешно выполнено. Для предотвращения непредвиденных сбоев можно использовать долговременные очереди, поскольку такого рода действия не нужно выполнять синхронно. Так что вы просто говорите «электронная почта отправлена». Обычно вы видите такой ответ, когда просите сбросить пароль.

• Обновите некоторую информацию в профиле пользователя: после того, как вы проверили новые данные на клиенте, скорее всего, команда тоже выполнится успешно, поскольку единственное, что может произойти, - ошибка базы данных (если вы используете базу данных). Опять же, даже это может быть смягчено с помощью длительных очередей. В этом случае вы просто показываете обновленное поле в той же форме. Хорошей практикой для SPA является создание полного хранилища данных на стороне клиента, как это делает Redux. В этом случае вы можете безопасно обновить сервер, отправив команду, а также обновив хранилище на стороне клиента, в результате чего в пользовательском интерфейсе отобразятся последние данные. Отказ от ответственности: некоторые ответы называют эту технику «обманом пользователя», но я не согласен с этим определением.

• Если у вас есть команды, склонные к ошибкам, вы можете использовать методы, которые уже описаны в других ответах, таких как веб-сокеты или события на стороне сервера, для обратной передачи ошибок. Это требует довольно много дополнительной работы. Вы также можете отправить команду и дождаться ответа или выполнить команды синхронно. Кто-то скажет: «Это не CQRS», но это будет просто еще одна догма, которую нужно оспорить. Обеспечение того, чтобы команда завершила выполнение в сочетании с предыдущим пунктом (хранилище данных на стороне клиента), будет хорошим решением.

Я не уверен, существует ли какой-либо метод 100% пуленепробиваемой проверки, который позволяет вам всегда показывать нестарелые данные из прочитанной модели. Я думаю, что это идет вразрез с принципами CQRS. Даже с событиями в реальном времени вы будете получать только события, которые указывают, что вы пишете, что модель была обновлена. Тем не менее, ваши прогнозы могли провалиться, и реакция на это - совсем другая история.

Однако я бы не стал так сильно концентрироваться на этом вопросе. Дело в том, что хорошо протестированные проекции и почти гарантированные команды будут работать очень хорошо. Для обработки ошибок в 90% случаев достаточно ручного или полуручного процесса для восстановления после этих ошибок. За последние 10% вы можете объединить общие сообщения об ошибках, выдаваемые с сервера: «извините, ваше действие XXX не удалось выполнить», и действия с высоким приоритетом могут иметь какой-то творческий процесс, но в действительности эти ситуации будут очень редкий.

Answer 4

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

Например, представьте, что мы находимся на экране списка, где пользователь может выполнять различные действия, одним из которых является добавление нового элемента в список.После выбора добавления элемента вы можете отобразить «Что бы вы хотели сделать дальше?»которые могут иметь «Добавить другой элемент», «Выполнить эту задачу», «Выполнить другую задачу», «Вернуться к списку».

К тому времени, когда они нажмут на опцию, данные будут иметь надеждубыл обновлен.

Кроме того, если вы используете пользовательский интерфейс на основе задач, вы можете анализировать шаблоны выполнения задач и использовать эти экраны «что бы вы хотели сделать дальше» для оптимизации пользовательского интерфейса.Подобно тому, как амазонки "другие люди тоже покупали эти вещи".

Answer 5

Я бы не стал обманывать пользователя или запрещать ему совершать какие-либо другие действия. Я бы предпочел потоковую передачу данных в интерфейс после того, как они были подтверждены стороной чтения. Давайте рассмотрим эти два случая:

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

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

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

Недостаток:

Результаты по-прежнему не будут немедленно отражены читающей стороной. Но, по крайней мере, в большинстве случаев пользователь сможет продолжить свою работу без блокировки пользовательским интерфейсом.

Answer 6

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

• электронной почты;
• SMS;
• пользовательский почтовый ящик (например, как почтовый ящик SO) ;
• независимо от того.

Например, почтовый клиент / служба:

• Я отправляю письмо не по адресу;
• почтовый сервис сообщает: «электронная почта успешно отправлена ​​:)»;
• через несколько минут я получаю письмо от службы: «электронная почта не может быть доставлена».

Я считаю, что это отличный способ проинформировать пользователя о недавнем сбое представляет ему панель ошибок при навигации по приложению .Пользовательский жест может потребоваться для отклонения этого предупреждения и т. Д.

Например: