DTO Pattern + Lazy Loading + Entity Framework + ASP.Net MVC + Auto Mapper

Во-первых, Извините за длинный вопрос, но я должен дать некоторую базовую информацию.

Мы создаем приложение, которое использует ASP.net MVC, JQuery Templates, Entity Framework, WCF, и мы использовали POCO в качестве нашего домена. В нашем приложении есть слой служб WCF для обмена данными с приложением ASP.net MVC, и он использует объекты передачи данных (DTO) из WCF в MVC.

Кроме того, приложение использует Lazy Загрузка в Entity Framework с помощью AutoMapper при преобразовании доменов-TO-DTO на нашем уровне обслуживания WCF.

Наша архитектура Backend следующим образом (Службы WCF → Менеджеры → Репозиторий → Структура сущностей (POCO))

В нашем приложении мы не используем View Models, так как нам не нужен другой слой отображения для приложения MVC, и мы используем только DTO как View Model.

Как правило, у нас есть нормальные и Lite DTO для домена, такие как Customer, CustomerLite и т.д. (Объект Lite имеет несколько свойств, чем Normal).

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

Например,

У нас есть страница просмотра клиента и наша иерархия DTO следующим образом

 public class CustomerViewDetailsDTO
 {
   public CustomerLiteDto Customer{get;set;}
   public OrderLiteDto Order{get;set;}
   public AddressLiteDto Address{get;set;}
 }

В этом случае нам не нужны некоторые поля OrderLiteDto для этого представления. Но некоторым другим представлениям нужны эти поля, поэтому, чтобы облегчить это, мы используем эту структуру.

Когда дело доходит до Auto Mapping, мы сопоставляем CustomerViewDetailsDTO, и мы получим дополнительные данные (которые не нужны для определенного вида) из Lazy Loading (Entity Framework).

Мои вопросы:

Есть ли какой-либо механизм, который мы можем использовать для повышения производительности при рассмотрении ремонтопригодности?
Можно ли использовать Automapper с другими функциями отображения на основе карты для того же DTO?

Ответ 1

Сначала не используйте Lazy Loading, так как, вероятно, это приведет к выбору проблем N + 1 или тому подобное.

Выбор N + 1 - это анти-шаблон доступа к данным, в котором база данных доступ к нему неоптимальным способом.

Другими словами, использование ленивой загрузки без загрузочных коллекций заставляет Entity Framework идти в базу данных и возвращать результаты назад по одной строке за раз.

Используйте jsRender для шаблонов, поскольку он намного быстрее, чем шаблоны JQuery: Render Bemchmark и здесь хорошая информация о том, как его использовать: Уменьшение кода JavaScript Использование шаблонов jsRender в приложениях HTML5

Как правило, у нас есть нормальные и Lite DTO для домена, такие как Customer, CustomerLite и т.д. (Объект Lite имеет несколько свойств, чем Normal).

Ваша нормальная DTO, вероятно, является ViewModel, поскольку ViewModels могут или не могут сопоставлять один-на-один с DTO, а ViewModels часто содержат логику, оттолкнутую назад от представления, или помогают с возвратом данных обратно в Модель при ответе пользователя. DTO не имеют никакого поведения, и их целью является уменьшение количества вызовов между уровнями приложения.

Есть ли какой-либо механизм, который мы можем использовать для повышения производительности при рассмотрении ремонтопригодности?

Используйте один ViewModel для одного вида, и вам не придется беспокоиться о ремонтопригодности. Лично я обычно создаю класс abtract, который является базой, и для редактирования создайте или перечислите i, наследуйте этот класс и добавляйте свойства, специфичные для представления. Таким образом, для примера Create view не требуется PropertyId (поскольку кто-то может захватить ваше сообщение и опубликовать его), так что только объекты Edit и List ViewModels имеют свойство PropertyId.

Можно ли использовать Automapper с другими функциями отображения на основе карты для того же DTO?

Вы можете использовать AutoMapper для определения каждой карты, но вопрос в том, насколько сложна карта. Используя один ViewModel для каждого вида, и ваши карты будут просты в написании и обслуживании. Я должен указать, что не рекомендуется использовать Automapper в коде доступа к данным как:

Один недостаток AutoMapper заключается в том, что проекция из объектов домена все еще заставляет весь объект домена запрашиваться и загружаться.

Источник: Автопроектирование запросов LINQ

Вы можете использовать набор расширений, которые ограничены на данный момент, чтобы ускорить ваше сопоставление в коде доступа к данным: Прекратить использование AutoMapper в вашем коде доступа к данным

Привет