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

читал несколько статей и сообщений Stackoverflow для преобразования объектов домена в DTO и опробовал их в своем коде. Когда дело доходит до тестирования и масштабируемости, я всегда сталкиваюсь с некоторыми проблемами. Мне известны следующие три возможных решения для преобразования доменных объектов в DTO. Большую часть времени я использую Spring.

Решение 1. Частный метод в сервисном слое для конвертации

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

@Service
public MyEntityService {

  public SomeDto getEntityById(Long id){
    SomeEntity dbResult = someDao.findById(id);
    SomeDto dtoResult = convert(dbResult);
    // ... more logic happens
    return dtoResult;
  }

  public SomeDto convert(SomeEntity entity){
   //... Object creation and using getter/setter for converting
  }
}

Плюсы:

легко реализоватьне требуется дополнительный класс для преобразования -> проект не взрывается с сущностями

Минусы:

проблемы при тестировании, какnew SomeEntity() используется в частном методе, и если объект глубоко вложен, я должен предоставить адекватный результат моегоwhen(someDao.findById(id)).thenReturn(alsoDeeplyNestedObject) чтобы избежать NullPointers, если преобразование также разрушает вложенную структуру

Решение 2. Дополнительный конструктор в DTO для преобразования сущности домена в DTO

Второе решение - добавить в конструктор DTO дополнительный конструктор для преобразования объекта в конструктор.

public class SomeDto {

 // ... some attributes

 public SomeDto(SomeEntity entity) {
  this.attribute = entity.getAttribute();
  // ... nesting convertion & convertion of lists and arrays
 }

}

Плюсы:

не требуется дополнительный класс для преобразованияпреобразование скрыто в объекте DTO -> сервисный код меньше

Минусы:

использованиеnew SomeDto() в служебном коде и поэтому я должен предоставить правильную структуру вложенных объектов в результате моегоsomeDao насмешливый.

Решение 3: Использование конвертера Spring или любого другого внешнего компонента для этого преобразования

Если недавно увидел, что Spring предлагает класс по причинам конвертации:Converter<S, T> но это решение обозначает каждый внешний класс, который выполняет преобразование. С помощью этого решения я внедряю конвертер в мой сервисный код и вызываю его, когда хочу преобразовать сущность домена в мой DTO.

Плюсы:

легко проверить, так как я могу посмеяться над результатом во время тестаразделение задач -> выделенный класс делает работу

Минусы:

не "масштабируется" так сильно, как растет моя модель предметной области. С большим количеством сущностей мне нужно создать два конвертера для каждой новой сущности (-> преобразование полномочий DTO и полномочий DTO)

У вас есть больше решений для моей проблемы и как вы справляетесь с этим? Вы создаете новый конвертер для каждого нового доменного объекта и можете «жить» с количеством классов в проекте?

Заранее спасибо!

Ответы на вопрос(4)

Ваш ответ на вопрос