Проверка разделения команд при повторных попытках - PullRequest
Новая
       9

Проверка разделения команд при повторных попытках

3 голосов
/ 05 мая 2010

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

Однако рассмотрите сценарий, в котором вы вводите данные, и хотите предотвратить дублирование.

Используя новый ввод данных о сотрудниках, например, реестр сотрудников, прорабатывая кучу анкет для ввода данных о новых сотрудниках:

  1. Возьмите верхний лист.
  2. Введите имя сотрудника и уникальный номер платежной ведомости в интерфейсе пользователя.
  3. Submit.
  4. Положите бумагу в «готовую стопку».
  5. Повтор.

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

Ответы [ 4 ]

1 голос
/ 10 мая 2010

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

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

Теперь главное, что CQRS может изменить, - это то, как мы реагируем на конфликт. Я вижу два возможных решения:

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

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

1 голос
/ 07 мая 2010

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

0 голосов
/ 07 мая 2010

Не могли бы вы отслеживать список уже введенных комбинаций сотрудников / номеров заработной платы на клиенте? Если это веб-клиент, может быть cookie, если толстый клиент, то память или что-то другое. Когда они впервые войдут в систему, очистите список и начните заново.

0 голосов
/ 05 мая 2010

Я предлагаю изменить рабочий процесс на этот

  1. Проверьте, занят ли верхний лист в базе данных (у вас должна быть таблица R, чтобы запомнить, была ли взята конкретная строка или нет), есливзято, затем верните ложь, если нет, то возьмите верхний лист.и установите флажок для «занятой» строки в таблице R
  2. Введите имя сотрудника и уникальный номер платежной ведомости в UI.
  3. Submit.
  4. Вставьте бумагу"завершенная куча".
  5. Повтор.

Шаг должен выполняться атомарно.

...