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

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

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

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

• Наборы данных и прямой ADO.NET и привяжите набор данных непосредственно к элементам управления экрана ** напишите прямой код SQL для загрузки набора данных ** используйте представления в базе данных для загрузки набора данных ** используйте сохраненные процедуры для загрузки набора данных

• объектов NHibernate и DTO / Viewmodel ** я обычно использую представления, идя по этому маршруту - я создаю набор представлений поверх схемы моего домена, которые денормализуют данные в нужную мне модель, а затем с помощью NH загрузите их через второй набор карт

• DTO / Automapper из модели предметной области ** мне не нравится этот подход, если я не знаю, что уже все из моей модели предметной области загружено в память. Я буду использовать такой инструмент, как Automapper, для передачи данных из моей модели предметной области в DTO / ViewModel

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

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

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

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

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

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

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

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