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

Ответ 1

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

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

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

Ответ 2

Вы можете использовать automapper, такой как тот, который написал Джимми Богард, который не имеет никакой связи между объектами и полагается на соглашения об именах,.

Ответ 3

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

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

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

Ответ 4

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

Скажи... Что-то вроде этого

class DTO {

     // attributes 

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

     // methods
}

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

Я могу предложить инструмент, который я создал, и с открытым исходным кодом размещен в 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();

Ответ 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?

Ответ 9

Другим вариантом будет использование ModelProjector. Он поддерживает все возможные сценарии и очень прост в использовании с минимальными затратами.

Ответ 10

Для этого мы можем использовать шаблон Factory, Memento и Builder. Фабрика скрывает подробности о том, как создать экземпляр модели домена из DTO. Memento позаботится о сериализации/десериализации модели домена в/из DTO и может даже получить доступ к частным членам. Builder позволяет отображать DTO в домены с удобным интерфейсом.

Ответ 11

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

Хранение карт в другом месте было бы единственной альтернативой - но куда это должно пойти? Я пытался представить картографические объекты/сервисы, но, после всего сказанного и сделанного, это выглядело как переобучение (и, вероятно, было). Я имел некоторый успех, используя Automapper и такие для небольших проектов, но такие инструменты, как Automapper, имеют свои собственные подводные камни. У меня было довольно трудно найти проблемы, связанные с отображениями, потому что отображения Automapper неявны и полностью отделены от остальной части вашего кода (не как "разделение интересов", а скорее как "где живёт забытое Богом отображение"), поэтому они иногда бывает трудно отследить. Нельзя сказать, что Automapper не имеет своего использования, потому что это делает. Я просто думаю, что картирование должно быть как можно более очевидным и прозрачным, чтобы избежать проблем.

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