Должен ли DTO создаваться объектом домена или из постоянства? ⇐ C#

[Anonymous]

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

• Сущности предметной области — это богатые классы, содержащие бизнес-логику (верно?) и, в зависимости от возможностей ORM может напрямую относиться к дизайну сохраняемости.
• DTO – это более простые классы, которые удаляют бизнес-логику для передачи данных внутренним и внешним клиентам. Иногда они сглажены, но не всегда.
• Модели просмотра – они похожи на DTO тем, что они проще и лишены бизнес-логики, но обычно они довольно плоские и часто содержат дополнительные элементы, относящиеся к пользовательскому интерфейсу, который они обслуживают.

Проблема, с которой я сталкиваюсь, заключается в том, что в некоторых случаях сопоставление сущностей домена или любых других персистентно-ориентированный класс в более простой объект, такой как DTO или ViewModel, не позволяет вам выполнять важную оптимизацию производительности.
Пример:
Предположим, у меня есть несколько объектов домена, которые выглядят следующим образом:

Код: Выделить всё

public class Event
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime EventDate { get; set; }

// These would be reference types in most ORMs
// Pretend in the setter I have logic to ensure the headliner =/= the opener
public Band Headliner { get; set; }
public Band Opener { get; set; }
}

public class Band
{
public int Id { get; set; }
public string Name { get; set; }
public Genre Genre { get; set; }
}

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

Код: Выделить всё

public class EventViewModel
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime EventDate { get; set; }

public int HeadlinerId { get; set; }
public string HeadlinerName { get; set; }
public int OpenerId { get; set; }
public string OpenerName { get; set; }
}

Часто люди просто извлекают полный объект домена со ссылками, а затем используют утилиту сопоставления для гидратации модели представления.
Однако предположим, что у меня есть десятки тысяч записей. Теперь ORM, вероятно, создает шквал запросов для заполнения полных ссылочных объектов (что может быть намного сложнее, чем в этом примере, с собственными ссылками). Вскоре производительность начинает серьезно падать.
В чем вопрос?
Я знаю, что я не единственный, кто столкнулся с этой проблемой, поэтому мне любопытно узнать, как люди поддерживают многоуровневое приложение, при этом учитывая необходимость поддерживать производительность при создании нескольких объектов, которые представляют одну и ту же базовую информацию о домене.
Неправильно иметь два события объекты, представляющие одни и те же сохраняемые данные, но в то же время не похоже, что уровень персистентности должен знать о DTO или моделях представлений, иначе какой смысл стремиться к разделению?
Так как же решить эту проблему? Знает ли постоянство о строгих, подробных представлениях сущностей предметной области, а также об облегченных изображениях данных в этих сущностях? Являются ли эти облегченные изображения DTO или каким-то облегченным объектом домена?