Каков правильный способ заполнения DTO

Question

Я использую DTO (объекты передачи данных) для передачи информации между различными уровнями приложения.

Какова наилучшая практика в отношении производительности и способа заполнения этих объектов? Должен ли я заполнять только минимальную требуемую информацию различными способами из моего уровня доступа к данным?

Скажем, у меня есть следующие классы:

public class Order 
{ 
    public int OrderNo; 
    public Customer Customer; 
    public double Total; 
} 

public class Customer 
{ 
    public int CustId; 
    public string CustName; 
    public Country Country; 
} 

public class Country 
{ 
    public int CountryId; 
    public string CountryName; 
} 

Что произойдет, если мне нужно, чтобы создать список заказов, содержащих OrderNo, CustName и COUNTRYNAME и в другой ситуации, различную информацию может быть из разных таблиц (или DTOS)? Было бы лучше использовать сгладить DTO только с обязательными полями или сделать запрос с помощью LINQ?

Надеюсь, я сделаю это достаточно ясно.

Спасибо вам за помощь!

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

Answer 1

На мой взгляд, вам нужно только DTO [см. Fowler's definition], если вы хотите передавать информацию по машинам или процессам. Например: когда вы хотите использовать свою (частную) бизнес-логику в богатом клиенте, который взаимодействует с сервером или физически отделяет обработку доступа к данным от вашей бизнес-обработки. DTO также может быть полезен, когда вы хотите делиться информацией между процессами на одном компьютере.

В таких случаях я бы создал DTO из бизнес-объектов с помощью Linq или другого настраиваемого кода. AutoMapper, предложенный @Tim, также может быть полезен.

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

Примечание:

Из Вашего вопроса, я получаю впечатление, что вы хотите использовать DTO к информации

передачи из данных -доступ слоя к бизнес-объектам в бизнес-слое

По-моему, это не проблема для многих, многих веб-приложений, где и доступ к данным, и бизнес ess логика выполняется на той же машине в том же процессе. Вам не понадобится DTO для извлечения бизнес-объектов из базы данных - вместо этого сохраняйте свои сущности непосредственно в базу данных и из нее. Для этого вы можете использовать ORM-инструмент или код пользовательского доступа к данным.

Обмен информацией между бизнес-слоями и слоями презентаций необязательно требует наличия DTO.

Answer 2

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

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

Что касается заполнения DTO, мы широко используем LINQ и AutoMapper в многоуровневом приложении ASP.NET MVC. AutoMapper чрезвычайно полезен при сопоставлении между нашими бизнес-объектами и объектами модели немого вида, переданными в представления. Хотя у нас нет самой большой БД в мире, мы имеем довольно сложную схему и на самом деле не пострадали от узких мест производительности в результате сопоставления.

В одном месте, где мы видели проблемы с производительностью, преждевременно оцениваются запросы LINQ, которые отбрасывают массивные графы объектов, а не только то, что требуется. Проверяя, что «выбрать новый» был выполнен в нужное время, я уменьшил один запрос, потянув 850 МБ данных по сети от БД до 1,3 МБ!