2012-06-24 2 views
6

Из того, что я прочитал, проекты CQRS включают асинхронные команды, где команды помещаются в очередь. Пользователь предполагает, что все в порядке, и опросы пользовательского интерфейса или через таймер возвращают некоторые каналы, если все работает или нет.Должны ли команды быть асинхронными в CQRS?

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

Итак, из пользовательского интерфейса я могу показать, что произошло перетаскивание, а затем с помощью некоторого таймера проверить, обновлена ​​ли моя прочитанная модель (т. Е. Проверить родительскую папку перетаскиваемой папки и если она установлена ​​правильно, я знаю, что это сработало).

Если пользователь выполнил несколько операций перетаскивания, мне пришлось бы вести список этих операций в пользовательском интерфейсе и проверять хранилище чтения (удаляя любые успешные команды из списка).

Там могут быть лучшие способы сделать это.

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

ответ

5

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

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

Если вы хотите представить текущее состояние системы всем пользователям, ваш ui должен будет выполнить всю работу, о которой вы беспокоитесь; это совсем не уникально для CQRS.

+0

Спасибо за ответ. –

+0

Я вижу это скорее как стремление информировать пользователей как можно скорее о том, успешны ли их действия или нет. И поэтому, на мой взгляд, это плохо с точки зрения удобства использования пользовательского интерфейса, чтобы пользователи могли весело перетаскивать папки только для «вызова сервера» несколько секунд спустя и выяснять, что все эти действия были отклонены - я думаю, что пользователь должен быть проинформирован сразу. Тот же случай для проблем с сохранением данных (думаю, валидация!), И большинство, если не все другие условия ошибки. – Dav

+0

«Стремление информировать пользователей как можно скорее о том, являются ли их действия успешными или нет» - это не универсальное требование, которое должна выполнять каждая система. Если текущее состояние приложения имеет решающее значение для определения действий, доступных для пользователя, то асинхронные команды, вероятно, не являются лучшим дизайнерским решением, но это не означает, что использование синхронных команд - это волшебная пуля, которая будет удерживать состояние от изменения * между командами, выпущенными одним пользователем *. – arootbeer

3

Вы можете очень хорошо использовать синхронные команды. Асинхронные команды не требуются для CQRS.

Смежные вопросы