Смешивание сущности с полезной нагрузкой (dto) в весенней загрузке - лучшая практика

Question

Хорошая ли практика, когда один класс одновременно является сущностью (сопоставленной и сохраненной в базе данных) и полезной нагрузкой (объект сериализуется и возвращается из конечной точки REST)?

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

Лично я считаю, что это плохая практика, потому что в таком классе мы смешиваем аннотации для сериализации в JSONи для отображения объекта в базу данных, что делает код трудным для чтения.

Но, возможно, есть и другие аргументы.Что ты думаешь?

Answer 1

Ну, у каждого дела есть свои достоинства.Но обычно в реальных случаях они разные.

Концептуально, то, что вы выставляете как API, вероятно, будет отличаться от того, что вы храните в базе данных, если только ваш сервис не очень тупой.

3 слоя разделены дляпричина.

Контроллер выступает в качестве внешнего интерфейса, получающего запросы в определенном формате.Это может быть полезная нагрузка JSON из запроса RESTful, это может быть просто отправка простой старой формы.Он выполняет проверку и предварительную обработку запроса, который должен быть передан другим службам или компонентам.

Служба действует как уровень бизнес-логики.То, что было передано в запросе, не обязательно отображает один в один на то, что обрабатывается на этом уровне.Он может вызывать другие службы, он может разбить запрос на более мелкие отдельные части, он может даже поставить запрос в очередь для последующей обработки, как это обычно делается в типах архитектур CQRS.Он может преобразовать полученный запрос в объекты для передачи в хранилище.Кроме того, служба может использоваться другими службами или несколькими контроллерами.

Хранилище 1016 * затем обрабатывает логику с объектами базы данных и их взаимосвязями.Объекты, которые он обрабатывает, будут более согласованы с таблицами базы данных и, будучи объектами, будут иметь более реляционный вид дизайна.

Еще одна вещь, которую вы должны иметь в виду, это то, что внутренняя реализация и репозиторий могут быть смоделированы не так, как API.Требуется много навыков и внимания для создания API, который абстрагируется до нужных уровней, является чистым и достаточно дружественным к пользователю, и большинство лучших практик предлагают на самом деле выполнить этот «контракт в первую очередь», не позволяя реализации API влиять на ваш DTO-дизайн..

Answer 2

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

Допустим, у вас есть клиент, клиент А.

Клиент А интегрируется в вашу систему через конечную точку Restful и ожидает информацию об учетной записи.Вы создаете версию конечной точки Rest и возвращаете версионный объект Account

@Entity
public class Account {
   private Long id;
   private String firstname;
   private String lastname;

   //Getters and setters are omitted for the sake of brevity
}

Клиент A доволен информацией и использует ее в течение 6 месяцев.

Через 6 месяцев ваша команда баз данных начинает процесс очистки / рефакторинга и меняет фамилию на фамилию и имя наназвание.Необходимо изменить следующее, поскольку все они могут касаться объекта:

1. Уровень базы данных
2. Уровень устойчивости
3. Бизнес-уровень
4. Уровень представления

Как видите, небольшие изменения вызывают много изменений.Это также нарушает контракт конечной точки Restful с поддержкой версий.

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