Вопрос по asp.net-mvc, entity-framework – DTO Pattern + Ленивая загрузка + Entity Framework + ASP.Net MVC + Auto Mapper

12

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

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

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

Наша архитектура бэкэнда выглядит следующим образом WCF Services -> Managers -> Repository -> Entity Framework (POCO))

В нашем приложении мы не используем модели представления, поскольку нам не нужен еще один слой отображения для приложения MVC, и мы используем только DTO в качестве моделей представления.

В общем, у нас есть обычные и облегченные 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 для этого представления. Но некоторые другие представления нуждаются в этих полях, поэтому для облегчения этого мы используем эту структуру.

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

Мои вопросы

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

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

Lengthy? Я бы хотел, чтобы каждый вопрос был таким коротким Gert Arnold

Ваш Ответ

1   ответ
11

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

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

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

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

В общем, у нас есть Normal и Lite DTO для таких доменов, как Customer, CustomerLite и т. Д. (У объекта Lite меньше свойств, чем у Normal).

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

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

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

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

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

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

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

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

С уважение

Спасибо за ответ, и это действительно ценно. Иногда отключение отложенной загрузки является орешником, поскольку мы должны вручную включать необходимые объединения. Я согласен с вами, что проблема N + 1 и ленивая загрузка должны решаться с осторожностью. Мы всегда используем Entity Profiler Efprof.com) проанализировать производительность с Entity Framework. Мы не используем Auto Mapper в нашем слое персистентности. В основном, я согласен с одной моделью представления для представления, и в нашем случае это станет одним DTO для страницы, которая не так удобна для поддержки. marvelTracker
Нет проблем. Да, efprofiler - отличная программа. Пожалуйста, отметьте это как ответ, если это была та информация, которая вам требовалась. Matija Grcic

Похожие вопросы