Это хорошая практика, чтобы объекты DTO были глубоко интегрированы в код?

Question

Я создаю довольно большое приложение, которое использует шаблон проектирования DAO / DTO для получения данных из базы данных.В приложении конкретный DTO стал «базовой структурой данных», так как на него ссылаются во всем проекте.Мне интересно, будет ли хорошей практикой так глубоко интегрировать этот DTO в проект, или мне нужен какой-то слой преобразования, где я конвертирую DTO в объекты не-DTO?

Я могу видетьпричины за и против того, чтобы этот слой преобразования.Например, если у нас действительно есть слой преобразования, то: 1) радикальные изменения в DTO могут привести к ошибкам во всем проекте, следовательно, наличие слоя преобразования изолирует ошибку в одной точке кода.2) Я могу добавить дополнительную логику в базовую структуру данных, которую нельзя добавить в DTO, потому что она генерируется автоматически.

Однако я также вижу недостатки в наличии слоя преобразования: 1) Код преобразования DTO должен быть согласованным при изменении DTO.Это добавляет еще один шаг, о котором должен знать программист, и, следовательно, более подвержен ошибкам.2) Это также приводит к дублированию кода, так как по большей части вы копируете средства доступа DTO.

Какой лучший путь?DTO повсюду или слой конверсии?Кто-нибудь может направить меня в правильном направлении?

Answer 1

Я думаю, что имя выдаст цель: Объект передачи данных. Передача данных.

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

Если ваши доменные объекты являются DTO, то вы либо выставляете свою доменную логику за пределы своей доменной модели, либо храните свою доменную логику где-то, кроме своих доменных объектов. Или оба.

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

Answer 2

Я бы посчитал DTO чем-то вроде анти-паттерна, пережитка того времени, когда постоянство EJB 1.0 было настолько болтливым, что DTO были необходимы для сокращения сетевого трафика.

Теперь я бы сказал, создавать модели объектов и спать по ночам. Сделайте их неизменными, если можете, и не беспокойтесь о DTO.

Переводы ради архитектурной чистоты тратят впустую циклы ЦП без особой ценности.