Проводники CQRS выполняются в определенном порядке

Question

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

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

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

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

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

В более поздней реализации мы собираемся использовать очередь событий, но на данный момент мы довольно застряли.

Любая идея была бы оценена! Спасибо, mosu '!

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

Answer 1

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

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

Подводя итог, команда Delete изменяет коллекцию на стороне записи, но команда Reoder - это просто настройка пользователя или коллекции. Следовательно, здесь нет параллелизма.

Update

на основе ваших комментариев и уточнений.

1. Конечно, вы можете и, возможно, должны ограничивать действия пользователя только одним в то время. Если время удаления и переупорядочения достаточно короткое. Это всегда вопрос о типе пользовательского опыта, которого вы просили достичь. Возьмем обычный пример системы заказа.После заказа, пользователь может почти сразу увидеть его в пользовательском интерфейсе, и статус будет примерно InProcess. Скорее всего, вы не позволите пользователю каким-либо образом изменить порядок, а это означает, что вы не собираетесь показывать какие-либо пользовательские элементы управления, такие как кнопка «Отмена» (конечно, это всего лишь пример). Следовательно, вы можете использовать этот подход здесь.
2. Если 2 пользователя могут изменить одну и ту же физическую коллекцию, здесь у вас нет выбора - вы работаете с общими данными и должна быть какая-то синхронизация. Например, если вы используете саги, может быть пара саг: сага о переупорядочении коллекции и сага о Делеции - они могут сотрудничать. Сначала был начат процесс удаления - совокупность агрегатов была отмечена как удаление в процессе, а затем сразу после начала саги о переупорядочении она попытается запустить процесс переупорядочения, но поскольку сага удаления не обрабатывается, она должна дождаться DeletedEvent и продолжить процесс после этого. то же самое, если операция переупорядочения началась сначала - сага Deletion должна подождать до некоторого события и продолжить после того, как это событие наступит.

Update

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

Вот типичные шаги в обработчике команды:

Это общая последовательность шагов обработчик команды следующим образом:

1. Validate команду на своих собственных достоинствах.
2. Загрузить агрегат.
3. Подтвердить команду в текущем состоянии агрегата.
4. Создайте новое событие, примените событие к агрегату в памяти.
5. Попытка сохранить агрегат. Если есть параллелизм конфликт на этом этапе, либо отказаться, либо повторить вещи с шага 2.

Вот ссылка, которая помогла мне много некоторое время назад: http://www.cqrs.nu/

Answer 2

Max предложения очень приветствуются и обычно они применяются.

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

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

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