2009-09-25 3 views
6

Посмотрев это видео по Greg Yound на DDDКак реализовать CQS с изменениями в памяти?

http://www.infoq.com/interviews/greg-young-ddd

мне было интересно, как вы могли бы реализовать Command-Query Separation (ОКК) с DDD, когда у вас есть в изменениях памяти?

С CQS у вас есть два репозитория, один для команд, один для запросов. Как и две группы объектов, объекты команд и объекты запроса. Объекты Command имеют только методы и не обладают свойствами, которые могут отображать форму объектов и не должны использоваться для отображения данных на экране. Объекты запроса, с другой стороны, используются для отображения данных на экране.

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

Не могли бы вы использовать CQS с чем-то похожим и редактировать экран в ASP.NET, где сделаны изменения в памяти, и экран нужно обновлять несколько раз с изменениями до того, как изменения сохраняются в базе данных?

Например

  1. Принести объект запроса из хранилища запроса и отображать его на экране
  2. я нажимаю редактировать
  3. Я refetch объект запроса из хранилища объектов запроса и отображать его на форма в режиме редактирования
  4. Я меняю значение на форму, которая автоматически возвращает назад и извлекает командный объект и выдает соответствующую команду
  5. ЧТО ДЕЛАТЬ: Мне теперь нужно отобразить upda когда команда произвела изменения в вычисленных полях. Поскольку объект команды не был сохранен в базе данных, я не могу использовать репозиторий запросов. И с CQS я не собираюсь выставлять форму объекта команды для отображения на экране. Как бы вы вернули объект запроса с обновленными изменениями для отображения на экране.

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

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

ответ

1

Если вы действительно хотите использовать CQS для этого, я бы сказал, что как репозиторий Query, так и Write repo имеют ссылку на один и тот же резервный магазин.Обычно эта ссылка осуществляется через внешнюю базу данных, но в вашем случае это может быть список <T> или аналогичный.

+1

Спасибо за ответ. Мне интересно, как обычный/хороший дизайн использовать CQS, когда изменения хранятся в памяти, а не сохраняются прямо в базе данных? Это в основном то, что мы придумали, это использовать репозитории сеансов, чтобы репозиторий запросов мог получить доступ к данным команды через переменную сеанса. Возможно, позже захотите репозитории HttpContext. Кто-нибудь видел это раньше? Мысли оценили. – Ian

+0

На мой взгляд, метод, используемый для управления источником данных, не должен опираться на тип источника данных. Шаблон репозитория позволяет отвлечь эти различия, позволяя вам обрабатывать любой источник данных, как если бы он представлял собой запрограммированную коллекцию объектов.Реализация целевого источника данных зависит от конкретных реализаций репозитория, поэтому теоретически вы должны иметь «InMemoryRepository» и «DatabaseRepository» - или что у вас есть. –

+0

Да, я понимаю, что вы можете поменять хранилище InMemory для репозитория базы данных. Часть значения CQS заключается в том, что вы выдаете команды в базу данных и отдельно извлекаете обновленные данные в репозиторий запросов. В памяти объект команды находится в сеансе, поэтому репозиторий запросов может только отбрасывать данные в объекте команды. С версией базы данных объект запроса может полностью отличаться от объекта команды, просто кажется, что память CQS намного ближе. Интересно, как это вписывается в то, что CQS пыталось достичь. – Ian

0

В памяти, вы обычно используете Observer design pattern.

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

+0

Не уверен, что если вы получаете мой вопрос. С помощью CQS вы отделяете записи от записей. Если репозиторий Query отделен от хранилища Write. Итак, если я не сохраняю объект домена в репозитории, как может репозиторий запросов получить данные? Мне нужен способ получить объект запроса от объекта домена с его обновленным состоянием, или вы говорите, что объект запроса будет наблюдать объект домена и обновлять его? Или, возможно, ввести репозиторий сеансов? – Ian

0

Unit of Work шаблон дизайна от Patterns of Enterprise Application Architecture соответствует CQS очень хорошо - это в основном большая команда, которая сохраняется в базе данных.

+0

Спасибо за ссылку, но все равно не отвечаю на мой вопрос. В основном с CQS у вас есть один объект, который имеет только методы (команды) и другой объект, который содержит форму объекта. Существует два репозитория: один для объекта команды и один для объекта запроса. Таким образом, вы никогда не используете объект команды для повторного заполнения экрана, вместо этого вы используете объект запроса. Не сохраняя изменения объекта команды в базе данных, как вы можете повторить изменения, вызванные вызовами команд? Поскольку изменений нет в базе данных, вы не можете использовать репозиторий запросов. – Ian

3

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

EG: пользователь взаимодействует с веб-страницей (допустим, сделайте регистрацию с помощью корзины покупок).

Несколько страниц, получающих информацию, создают команду. Команда не отправляется, пока пользователь на самом деле проверяет, где вся информация отправлена ​​в одной команде в домен, назовем ее командой «CheckOut».

Представленные модели весьма полезны при абстрагировании этого типа взаимодействия.

Надеюсь, это поможет.

Грег

+0

Hi Greg, У вас есть примеры этого? В настоящий момент я спустился по маршруту объекта запроса и поместил его в объект «корзина», который сериализует объект запроса, чтобы разрешить изменения между postbacks (также может использовать сеанс). По завершении обновления объекта он передается в объект команды. Если бы у меня было больше времени, вы могли бы использовать другой объект, кроме объекта запроса, для хранения этих изменений при редактировании, например, в модели презентации. Я использую тот же объект для отображения и редактирования с помощью, это то же самое с предлагаемой моделью представления? Спасибо – Ian

1

Кроме того, для остальной части вашей проблемы ...

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

+0

Не уверен, что это относится только к моей ситуации, пока у вас есть только одна база данных, поэтому не нужно беспокоиться об обновлении хранилища отчетов, а в объектах команд используется NHibernate, поэтому изменения сохраняются обратно в базу данных. Или это относится к моей ситуации? Не знаете, что касается вас, когда речь идет? – Ian

-2

JdonFramework является основой Java CQRS DDD, это поставить события домена + Асинхронный шаблон, более подробно https://jdon.dev.java.net/