CQRS: одна модель чтения на экран со сложным пользовательским интерфейсом / несколькими измерениями данных

Question

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

Представьте себе сценарий, где у меня есть OrderDetailView, для экрана, который отображает детали заказа (строки заказа и т. д. c).

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

Вопросы:

• Создать ли для этого экрана отдельный ViewModel? Я борюсь с его названием, но, может быть, что-то вроде OrderDeliveryView? Или AssignDeliveryToOrderView. Для этих более сложных экранов целесообразно ли называть имя действия, которое в конечном итоге будет выполнено?

• Наши модели чтения находятся в базе данных SQL. Единственный способ сохранить детали заказа и список компаний доставки для представления - использовать две отдельные таблицы. Обе таблицы будут обновляться из соответствующих событий через нормализатор OrderDeliveryView.

• Если это так, то лучше просто использовать существующий OrderDetailView и вызвать второй запрос из пользовательский интерфейс: GetAvailableDeliveryCompanies, который будет возвращать DeliveryCompanyListView. Эти модели более точно следуют примерам, которые я видел.

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

Answer 1

Модель, которую вы используете в своем пользовательском интерфейсе, не обязательно должна быть такой же, как вы храните. Я бы go создал отдельную ViewModel для каждого экрана, который у вас есть.

При этом в зависимости от технологии вы можете «повторно использовать» ViewModel. Например, с ASP. NET существует понятие Partial View. То есть вы можете создать общий View (и ViewModel) для повторного использования на нескольких экранах / страницах.

Views / Tables на SQL можно оптимизировать для они получены. Но это не мешает вам иметь несколько вызовов в БД для одного ViewModel / экрана.

Когда дело доходит до именования ViewModel, я предлагаю именовать его в соответствии с операциями, которые он выполняет с пользовательским интерфейсом, а не связывать его с хранилищем данных.