Сервисный уровень DTO - большие сложные интерактивные объекты, подобные отчету

Question

У меня есть объекты собрания, которые составляют основу системы планирования, из которых gridviews используются для отображения важной информации. Это предназначено для планирования работы сотрудников на собраниях, а также для сотрудников, чтобы посмотреть, что было запланировано.

Я пытаюсь следовать принципам DDD, но мне трудно понять, что нужно передать с моего уровня обслуживания до области презентации системы. Это связано с тем, что расписание может быть большим и фактически состоит из множества различных элементов системы. Например. Имя клиента, адрес, информация о событии, группа и т. Д., Все из которых необходимы планировщику собрания для принятия решения.

В дополнение к этому планировщику необходимо изменить значения в этом расписании и передать его обратно на уровень обслуживания (например, назначить сотрудников из выпадающих списков, возможно, изменить группу и т. Д.). Таким образом, информация на самом деле не «readonly» - с ней нужно взаимодействовать. то есть. Это не просто отчет.

Наш текущий подход заключается в заполнении сглаженного «объекта расписания» из SQL, который построен из небольших частей различных объектов домена. Это довольно сложный запрос. Когда изменения были сделаны, они затем передаются обратно на сервисный уровень, и служба будет извлекать объекты домена, о которых идет речь, и запускать бизнес-методы на объектах домена с использованием информации из DTO.

Мой вопрос в том, что это правильный подход? то есть. Продолжайте генерировать большие пользовательские объекты из SQL, а затем переходите с объектов Service Layer to Presentation Layer, которые очень похожи на View Models?

UPDATE из-за ответ

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

• Client находится в одной группе по умолчанию

• Клиент имеет один открытый случай, но многие закрытые

• случаи имеют много совещаний

• Встреча много назначенных сотрудников

• Знакомства ИНГ есть много причин

• Встреча может получить планируются к различным группам

• Сотрудники могут быть связаны со многими группами.

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

Планировщик может видеть имя клиента, адрес клиента, информацию о событии, MeetingTime, MeetingType, MeetingReasons, запланированные группы (showstrail), назначенные сотрудники (также скрытые идентификаторы сотрудников).

Редактируемые поля назначают раскрывающийся список сотрудников и группу по расписанию.

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

Таким образом, я полагаю, чтобы обновить, использует запрос для заполнения объекта, который содержит все выше приемлемо, чтобы передать, как один слиты DTO? А если нет, как бы вы к нему подошли? (приводя некоторые примеры вызовов к уровню обслуживания и немного объясняя, как вы понимаете, что ORM выбирает данные, сохраняющие в виду производительность)

Answer 1

В сервисном слое и ниже я рассматривал бы каждый объект (см. совокупные корни в DDD) отдельно по отношению к его транзакционной границе. То есть даже если вы могли бы обновить клиент и случай в том же представлении пользовательского интерфейса, было бы лучше всего изменить транзакцию на клиенте, а затем изменить этот случай. Чем больше вы пытаетесь изменить в одной транзакции, тем больше вы можете столкнуться с другими пользователями.

Несмотря на то, что ваше расписание велико и может содержать много объектов, уровень обслуживания должен снова обрабатывать каждый объект (совокупный корень) отдельно, а затем объединяться вместе в новую модель представления. К сожалению, на проектах с коричневым полем в SQL может возникнуть много логики, и массивные объединения нескольких таблиц могут усложнить реорганизацию более атомных запросов, которые делают именно то, что необходимо. Старая школа, ориентированная на данные, «делать все, что вы можете в базе данных», идет вразрез со всем DDD.

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

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

По моему мнению, ориентированные на данные, нормализованные приложения данных имели свой день (они имели смысл в 1970-х годах, когда место на жестком диске было дорого), и все приложения должны двигаться к более современным практикам. В действительности, только когда устаревшие системы сканируют на коленях, заинтересованные стороны обычно вкладывают деньги в поисках альтернатив (обычно после заполнения каждого последнего сервера оперативной памятью). Возможно, было бы возможно или лучше убедить их реорганизовать небольшие секции за раз.