Обтекание dto внутри бизнес-объекта - хорошая идея?

Question

Мы начинаем новую архитектуру mulit-tier. В прошлом я использовал AutoMapper для сопоставления объектов передачи данных с бизнес-объектами и наоборот. Коллега предположил, что вместо сопоставления мы должны обернуть dto внутри бизнес-объекта. Возможно, путем ввода dto в конструкторе бизнес-объекта. Затем мы можем получить доступ к значениям свойств dto на лету без отображения.

Вопрос:

Этот подход рекомендуется?

Я знаю, что если бизнес-объект знает, что вы вводите тугое соединение. Кроме того, вы теряете некоторую гибкость, создавая связь 1: 1 между бизнес-объектом и dto, которая обычно - с гибким отображением - будет отношением n: m.

(см: Best Practices For Mapping DTO to Domain Object?)

Является ли это недостатком причина никто, кажется, использует подход обертку или я скучаю коснуться?

Вот краткий демо, что я имею в виду "оборачивания":

public class BusinessObject 
 
{ 
 
    private Dto dto; 
 

 
    public BusinessObject() 
 
    { 
 
     this.dto = new Dto(); 
 
    } 
 

 
    public BusinessObject(Dto dto) 
 
    { 
 
     this.dto = dto; 
 
    } 
 

 

 
    public int Id 
 
    { 
 
     get { return dto.Id; } 
 
     set { dto.Id = value; } 
 
    } 
 
} 
 

 
public class Dto 
 
{ 
 
    public int Id { get; set; } 
 
}

мотки за вашу помощь!

Торстен

Answer 1

Это спорный. Впервые я увидел этот подход в этом blog post.

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

Есть некоторые недостатки этого подхода. Как вы указали, вы более или менее привязаны к 1-1 картированию сейчас. Другим недостатком является то, что вы теряете на любом validation or business logic, что ваши бизнес-объекты могут принудительно выполнять определенные свойства вашего объекта (поскольку DTO теперь владеет ими).

Достаточно большой недостаток для наложения DTO в бизнес-объект (POCO) - это вид поведения, который он может оставить в коде, где объекты, как правило, больше не управляют своим собственным состоянием. Как expressed here, это может затруднить определение кода, ответственного за определенную функциональность. Это также делает использование классов более опасным, поскольку объекты имеют свое состояние снаружи.