Рекомендации по сопоставлению объекта DTO с доменом?

Question

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

Ситуация:

У нас есть много объектов домена. Мы используем модель CSLA, поэтому наши объекты домена могут быть довольно сложными и содержать свой собственный доступ к данным. Вы не хотите передавать их по проводам. Мы собираемся написать несколько новых сервисов, которые возвратят данные в нескольких форматах (.Net, JSON и т. Д.). Для этого (и по другим причинам) мы также создаем обедненный объект передачи данных, чтобы пройти по проводам.

Вопрос в том, как должен быть подключен объект DTO и Domain?

Моя первая реакция заключается в использовании Fowler, DTO pattern-type solution. Я видел это много раз, и мне это кажется правильным. Объект домена не содержит ссылки на DTO. Для создания DTO из объекта домена вызывается внешний объект («сопоставитель» или «ассемблер»). Обычно на стороне объекта домена есть ORM. Недостатком этого является то, что «картограф» имеет тенденцию становиться чрезвычайно сложным для любой реальной ситуации и может быть очень хрупким.

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

Есть ли другие способы? Один из способов, над которым стоит использовать? Если да, то нет?

Спасибо за любое понимание заранее.

Answer 1

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

Лично я пытаюсь сохранить отображение из своих объектов домена и возложить ответственность на то, что я называю «Уровень менеджера/службы». Это слой, который находится между приложением и хранилищем (-ями), и обеспечивает бизнес-логику, такую ​​как координация рабочего процесса (если вы изменяете A, вам, возможно, придется также изменить B, поэтому служба A будет работать с сервисом B).

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

Answer 2

Вы можете использовать automapper, такой как the one written by Jimmy Bogard, который не имеет связи между объектами и полагается на соглашения об именах.

Answer 3

Вы также можете попробовать Отис, сопоставление объектов с объектами. Понятия похожи на отображение NHibernate (атрибут или XML).

http://code.google.com/p/otis-lib/wiki/GettingStarted

Answer 4

Другое возможное решение: http://glue.codeplex.com.

Особенность:

• Двунаправленное отображение
• Автоматического отображения
• Преобразования между различными типами
• Уплотненного картографированием и уплощением
• Списков и массивами
• Проверка отношений
• Тестирования отображение
• свойства, поля и методы

Answer 5

Мы используем шаблоны T4 для создания классов отображения.

Pro - человекообразный код, доступный во время компиляции, быстрее, чем среда выполнения. 100% контроль над кодом (может использовать частичные методы/шаблон шаблона для расширения функциональности на разовой основе)

Con's - исключая определенные свойства, коллекции объектов домена и т. Д., Изучая синтаксис T4.

Answer 6

Я предлагаю инструмент, который я создал, и с открытым исходным кодом размещен на CodePlex: EntitiesToDTOs.

Сопоставление с DTO на Entity и наоборот осуществляется с помощью методов расширения, они составляют сторону Ассемблера каждого конца.

Вы заканчиваете с кодом, как:

Foo entity = new Foo(); 
FooDTO dto = entity.ToDTO(); 
entity = dto.ToEntity(); 

List<Foo> entityList = new List<Foo>(); 
List<FooDTO> dtoList = entityList.ToDTOs(); 
entityList = dtoList.ToEntities(); 

Answer 7

Как вы видите, чтобы реализовать конструктор внутри класса DTO, который принимает в качестве параметра объекта домена?

Say ... Что-то вроде этого

class DTO { 

    // attributes 

    public DTO (DomainObject domainObject) { 
      this.prop = domainObject.getProp(); 
    } 

    // methods 
} 

Answer 8

Почему не мы можем сделать, как это?

class UserDTO { 
} 

class AdminDTO { 
} 

class DomainObject { 

// attributes 
public DomainObject(DTO dto) { 
     this.dto = dto; 
}  

// methods 
public function isActive() { 
     return (this.dto.getStatus() == 'ACTIVE') 
} 

public function isModeratorAdmin() { 
     return (this.dto.getAdminRole() == 'moderator') 
} 

} 


userdto = new UserDTO(); 
userdto.setStatus('ACTIVE'); 

obj = new DomainObject(userdto) 
if(obj.isActive()) { 
    //print active 
} 

admindto = new AdminDTO(); 
admindto.setAdminRole('moderator'); 

obj = new DomainObject(admindto) 
if(obj.isModeratorAdmin()) { 
    //print some thing 
} 

@FrederikPrijck (или) кто-то: Просьба предложить. В приведенном выше примере DomainObject зависит от DTO. Таким образом, я могу избежать кода для создания сопоставления dto < -> domainobject.

или класс DomainObject может расширять класс DTO?