Шаблон DTO + ленивая загрузка + Entity Framework + ASP.Net MVC + Auto Mapper

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

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

кроме того, приложение использует ленивую загрузку в Entity Framework с помощью AutoMapper при преобразовании домена в DTOs в нашем слое сервиса WCF.

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

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

вообще, мы имеем нормальные и облегченные Дтос для домена как клиент, Кустомерлите, ЕТК (Lite объект имея несколько свойств, чем обычно).

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

например,

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

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

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

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

Мои Вопросы:

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

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

12
asp.net-mvc automapper dto entity-framework lazy-loading

1 ответов

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

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

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

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

вообще, мы имеем нормальное и облегченное Дтос для домена как клиент, CustomerLite и т. д. (объект Lite имеет несколько свойств, чем обычно).

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

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

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

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

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

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

источник: Autoprojecting по LINQ запросы

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

в отношении

11