CQRS - сторона запроса

Многие статьи blogsphere, связанные с разделением CQRS (команда query repsonsibility), по-видимому, подразумевают, что все экраны/режимы просмотра являются плоскими. например Имя, возраст, место рождения и т.д. И, следовательно, предположение о том, что внедрение мудрено, мы вставляем их в быстрый источник чтения и т.д. Отдельную таблицу для каждого представления mySQL и т.д. И вытаскиваем их с помощью чего-то вроде примитивного SqlDataReader, пинаем этого противного nhibernate ORM и т.д.

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

Итак, мой вопрос заключается в том, как люди обращаются к экрану, где, например, он отображает сводку сведений о клиенте, а затем список своих заказов с ссылкой [подробнее] и т.д.

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

В качестве альтернативы (это начинает казаться yuck) в таблице CustomerSummaryView есть столбец text/big (независимо от типа в вашем DB), называемый Orders, а столбцы для сетки экрана сводки заказов разделены и строки by |, Даже с XML-типом данных он все еще грязный.

Любые мысли об оптимальной практике?

Ответ 1

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

Но это на самом деле просто предназначено для того, чтобы вести точку дома... Неверно, что у вас должна быть только одна таблица для каждой модели представления (хотя в большинстве случаев вы, вероятно, должны). То, что эти утверждения пытаются сказать, заключается в следующем: "Вы должны избавиться от каких-либо правил, которые вы так долго следили за нормализацией. С архитектурой CQRS у вас есть возможность сделать таблицы базы данных в вашем канале запросов которые полностью сформированы в соответствии с потребностями вашего взгляда и ничто иное. Убедитесь, что вы в полной мере воспользовались этим. Не ходите на полпути, нормализуя эти таблицы только потому, что это то, что вы привыкли делать. Вместо этого, продолжайте и делайте вещи, которые раньше считались немыслимыми, например, создание одной таблицы базы данных для каждой модели представления или создание абсолютно стандартных таблиц модели просмотра."

Есть еще такие случаи, как ваша, где схема, которая наилучшим образом удовлетворит ваши потребности, будет иметь несколько таблиц. Вы можете даже (не дай бог) сделать Присоединиться или два. Это прекрасно, если вы действительно разработали таблицы базы данных для обслуживания своего представления, а не наоборот. Но будьте осторожны, легко скользить по склону нормализации и обмена данными между многими представлениями в базе данных запросов. Не ходи туда... просто нет причин, и это требует больше затрат, чем пользы. Основная цель заключается в следующем: логика View View должна быть мертвой, мертвой просто. Вы хотите, чтобы интеллектуальные правила находились на Командной стороне дома, и немного в Подписчиках, которые заполняют данные в канале Запроса. Таким образом, код, который читается из базы данных Query и показывает данные на экране, должен быть мертвым простым (почти таким же простым, как "пассивное представление" ).

Обновление:. В качестве дополнительной поддержки утверждения о том, что "запрещено" делать некоторые объединения до тех пор, пока вы разработали форму базы данных, чтобы наилучшим образом выполнить задачу, которую вы достигаете, рассмотрите OLAP. Звездная схема является прекрасным примером схемы базы данных, предназначенной для поддержки чтения, которая идеально вписывается в Query-сторону CQRS и связана с объединениями. Соединения остаются простыми, и они имеют место для дальнейшего улучшения целей задач чтения, выполняемых с базой данных.

Ответ 2

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

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

Вот некоторые из способов, с которыми я справляюсь, в зависимости от приложения, над которым я работаю, в С#/.NET:

Наборы данных и прямой ADO.NET и привязать набор данных непосредственно к элементам управления экраном ** написать прямой код SQL для загрузки набора данных ** использовать представления в базе данных для загрузки набора данных ** использовать хранимые procs для загрузки набора данных
Объекты NHibernate и DTO/Viewmodel ** Обычно я использую представления при сходе по этому маршруту - я создам набор представлений поверх моей схемы домена, которые денормализуют данные в нужную мне модель, а затем используют NH для ее загрузки через второй набор карты
DTO/Automapper из модели домена ** Мне не нравится этот подход, если я не знаю, что у меня уже есть все, что загружено в мою модель домена. я буду использовать инструмент, например Automapper, для передачи данных из моей модели домена в DTO/ViewModel

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

Ответ 3

Я думаю, что людям не хватает точки CQS (или CQRS, то же самое на самом деле). CQR - это просто образец, чтобы сказать, что у вас должны быть отдельные модели для чтения и записи. Все эти модели полностью соответствуют вашим требованиям к внедрению.

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

Ответ 4

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

Ответ 5

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

На всякий случай, если вы сочтете это полезным и хотите увидеть некоторые образцы кода, я написал более подробный ответ в своем блоге. Вы можете найти сообщение здесь: http://danielwhittaker.me/2014/10/05/build-master-details-view-using-cqrs-event-sourcing/