У меня есть объекты Meeting, которые составляют основу системы планирования, в которой gridviews используются для отображения важной информации. Это делается для планирования совещаний сотрудников и для просмотра сотрудниками того, что было запланировано.
Я пытался следовать принципам DDD, но у меня возникли трудности с пониманием того, что нужно передать с моего сервисного уровня в область представления системы. Это связано с тем, что расписание может быть БОЛЬШИМ и на самом деле состоит из множества различных элементов системы. Например. Имя клиента, адрес, информация о деле, группа и т. д. — все это необходимо планировщику собрания для принятия решения.
В дополнение к этому планировщик должен изменить значения в этом расписании и передать их обратно на уровень службы (например, назначить сотрудников из раскрывающихся списков, возможно, изменить группу и т. д.). Таким образом, информация на самом деле не «только для чтения» — с ней нужно взаимодействовать. т.е. Это не просто отчет.
Наш текущий подход заключается в заполнении плоского «Объекта расписания» из SQL, который состоит из небольших частей различных объектов предметной области. Это довольно сложный запрос. Когда изменения были внесены, они затем передаются обратно на уровень службы, и служба извлекает рассматриваемые объекты домена и запускает бизнес-методы для объектов домена, используя информацию из DTO.
У меня вопрос, это правильный подход? т.е. Продолжать генерировать большие настраиваемые объекты из SQL, а затем передавать из сервисного уровня в объекты уровня представления, которые очень похожи на модели представления?
ОБНОВЛЕНИЕ в связи с ответом
Чтобы дать представление о количестве взаимосвязей сущностей/агрегатов. (это запутанный пример, поэтому здесь важны отношения)
Клиент находится в одной группе по умолчанию
У клиента есть одно открытое дело, но много закрытых
Дела имеют много встреч
Совещание имеет много назначенных сотрудников
Встреча имеет много причин
Встреча может быть запланирована для разных групп
Сотрудники могут быть связаны со многими группами.
В расписании необходимо загрузить все встречи в открытых делах, принадлежащих пациентам, которые находятся в тех же группах, что и сотрудник.
Планировщик может видеть имя клиента, адрес клиента, информацию о деле, время встречи, тип встречи, причины встречи, запланированные группы (s) (showstrail), назначенных сотрудников (также имеет скрытые идентификаторы сотрудников).
Редактируемые поля назначают раскрывающиеся списки сотрудников и запланированные группы.
- Расписание может быть до двухсот строк.
- DTO происходит от WCF, поэтому доступ к модели домена осуществляется выше этого уровня службы, а не ниже.
- Бизнес-вызовы модели предметной области, используемые службой на основе переданных значений DTO, а репозитории обрабатывают вставки/обновления.
Итак, я полагаю, чтобы обновить, использует ли запрос для заполнения объекта, который содержит все вышеперечисленное, приемлемо для передачи в качестве одного объединенного DTO? А если нет, то как бы вы к этому подошли? (приведите несколько примеров вызовов сервисного уровня и немного объясните, как вы понимаете, как ORM извлекает данные с учетом производительности)
