В общем Значения объектов должны быть неизменными. Как Integer или String объекты в Java. Мы можем использовать их для передачи данных между уровнями программного обеспечения. Если программные слои или службы работают в разных удаленных узлах, например в среде микросервисов или в устаревшем Java Enterprise App. Мы должны сделать почти точные копии двух классов. Именно здесь мы встретили DTO.
|-----------| |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------| |--------------|
В устаревших Java Enterprise Systems DTO могут содержать различные компоненты EJB.
Я не знаю, является ли это лучшей практикой или нет, но я лично использую Объекты значения в своих Spring MVC / Boot Projects, как это:
|------------| |------------------| |------------|
-> Form | | -> Form | | -> Entity | |
| Controller | | Service / Facade | | Repository |
<- View | | <- View | | <- Entity / Projection View | |
|------------| |------------------| |------------|
Контроллер * Слой 1018 * не знает, что это за сущности. Он связывается с Форма и Просмотр значений объектов . Объекты формы имеют аннотации проверки JSR 303 (например, @NotNull) и Объекты представления значений имеют аннотации Джексона для настраиваемой сериализации. (например, @JsonIgnore)
Сервисный уровень связывается с репозитарием через объекты Entity. Объекты Entity имеют аннотации JPA / Hibernate / Spring Data. Каждый уровень связывается только с нижним уровнем. Межуровневая связь запрещена из-за циклической / циклической зависимости.
User Service ----> XX CANNOT CALL XX ----> Order Service
Некоторые ORM Каркасы имеют возможность проецирования с использованием дополнительных интерфейсов или классов. Таким образом, репозитории могут возвращать объекты View напрямую. Там для вас не нужны дополнительные преобразования.
Например, это наш пользовательский объект:
@Entity
public final class User {
private String id;
private String firstname;
private String lastname;
private String phone;
private String fax;
private String address;
// Accessors ...
}
Но вы должны вернуть список пользователей, разбитых на страницы, которые содержат только имя, имя, фамилию. Затем вы можете создать объект View Value для проекции ORM.
public final class UserListItemView {
private String id;
private String firstname;
private String lastname;
// Accessors ...
}
Вы можете легко получить постраничный результат из слоя хранилища. Благодаря весне вы также можете использовать только интерфейсы для проекций.
List<UserListItemView> find(Pageable pageable);
Не беспокойтесь о других операциях преобразования * Метод 1043 * отлично работает.