Dto java что это

Data Transfer Object (Объект передачи данных)

Объект, который пересылает данные между процессами для уменьшения количества вызовов методов.

При работе с удалённым интерфейсом, таким как, например, Remote Facade, каждый запрос к нему достаточно затратен. В результате, приходится уменьшать количество вызовов, что означает необходимость передачи большего количества данных за один вызов. Чтобы реализовать это, как вариант, можно использовать множество параметров. Однако, при этом зачастую код получается неуклюжим и неудобным. Также это часто невозможно в таких языках, как Java, которые возвращают лишь одно значение.

Решением здесь является паттерн Data Transfer Object , который может хранить всю необходимую для вызова информацию. Он должен быть сериализуемым для удобной передачи по сети. Обычно используется объект-сборщик для передачи данных между DTO и объектами в приложении.

В сообществе Sun многие используют термин «Value Object» для обозначения этого паттерна. Мартин Фаулер подразумевает под этим термином ( Value Object ) несколько иной паттерн. Обсуждение этого можно прочесть в его книге P of EEA на странице 487.

Использована иллюстрация с сайта Мартина Фаулера.

Главная
Список паттернов
Сайт создан и поддерживается Василием Кулаковым.

Создание объектов передачи данных (DTO)

Сейчас наш веб-API предоставляет клиенту сущности базы данных. Клиент получает данные, которые сопоставляют непосредственно с таблицами базы данных. Однако это не всегда хорошая идея. Иногда требуется изменить форму данных, отправляемых клиенту. Например, можно сделать следующее:

Удалите циклические ссылки (см. предыдущий раздел).
Скрытие определенных свойств, которые клиенты не должны просматривать.
Пропуск некоторых свойств, чтобы уменьшить размер полезной нагрузки.
Плоские графы объектов, содержащие вложенные объекты, чтобы сделать их более удобными для клиентов.
Избегайте уязвимостей с избыточной публикацией. (Обсуждение чрезмерной публикации см. в разделе Проверка модели .)
Отделите уровень служб от уровня базы данных.

Для этого можно определить объект передачи данных (DTO). DTO — это объект, определяющий способ отправки данных по сети. Давайте посмотрим, как это работает с сущностью Book. В папке Models добавьте два класса DTO:

namespace BookService.Models < public class BookDto < public int Id < get; set; >public string Title < get; set; >public string AuthorName < get; set; >> > namespace BookService.Models < public class BookDetailDto < public int Id < get; set; >public string Title < get; set; >public int Year < get; set; >public decimal Price < get; set; >public string AuthorName < get; set; >public string Genre < get; set; >> >

Класс BookDetailDto включает все свойства из модели Book, за исключением того, что AuthorName является строкой, которая будет содержать имя автора. Класс BookDto содержит подмножество свойств из BookDetailDto .

Затем замените два метода GET в BooksController классе версиями, возвращающими DTO. Мы будем использовать оператор LINQ Select для преобразования сущностей Book в DTO.

// GET api/Books public IQueryable GetBooks() < var books = from b in db.Books select new BookDto() < Title = b.Title, AuthorName = b.Author.Name >; return books; > // GET api/Books/5 [ResponseType(typeof(BookDetailDto))] public async Task GetBook(int id) < var book = await db.Books.Include(b =>b.Author).Select(b => new BookDetailDto() < Title = b.Title, Year = b.Year, Price = b.Price, AuthorName = b.Author.Name, Genre = b.Genre >).SingleOrDefaultAsync(b => b.Id == id); if (book == null) < return NotFound(); >return Ok(book); >

Ниже приведен SQL, созданный новым GetBooks методом . Вы видите, что EF преобразует LINQ Select в инструкцию SQL SELECT.

SELECT [Extent1].[Id] AS [Id], [Extent1].[Title] AS [Title], [Extent2].[Name] AS [Name] FROM [dbo].[Books] AS [Extent1] INNER JOIN [dbo].[Authors] AS [Extent2] ON [Extent1].[AuthorId] = [Extent2].[Id]

Наконец, измените метод , PostBook чтобы он возвращал DTO.

[ResponseType(typeof(BookDto))] public async Task PostBook(Book book) < if (!ModelState.IsValid) < return BadRequest(ModelState); >db.Books.Add(book); await db.SaveChangesAsync(); // New code: // Load author name db.Entry(book).Reference(x => x.Author).Load(); var dto = new BookDto() < Title = book.Title, AuthorName = book.Author.Name >; return CreatedAtRoute("DefaultApi", new < >, dto); >

В этом руководстве мы преобразуем В DTO вручную в коде. Другой вариант — использовать библиотеку, например AutoMapper , которая обрабатывает преобразование автоматически.

Основы проектирования и дизайна

Данный модуль является чисто теоретическим. Практическое задание в него не включено.

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

Любое приложение работает с какими-либо данными: одни обрабатывают платежи, другие показывают доступные товары в интернет-магазине, а третьи выполняют поисковые запросы, составленные пользователем.
Во всех этих случаях у нас есть бизнес-домен — банк, интернет-магазин или поисковая система.

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

Пример: Банковская система (упрощенно).
Сущности: Пользователь, организация, счет, платеж, депозит, карта.
Связи: Пользователь принадлежит организации. У пользователя может быть много счетов. Организация делает платеж другой организации. Пользователь открывает депозит. Пользователь заводит карту.

Entity

Сущности в контексте приложения обычно называются Entity.

Entity — сущность из бизнес-домена, представленная в нашей программе как класс, в котором есть только поля, геттеры и сеттеры. Никакая логика не должна содержаться в этом классе.

Пример Entity — сущность ипотечного займа.
Она используется при сохранении и получении данных из базы через слой Repository. Пример:

package ru.bank.abc.entity; /** * Ипотечный займ (упрощенный вариант) */ public class Mortgage  /** * Продукт (например Семейная ипотека) */ private Product product; /** * Размер заемных средств */ private BigDecimal amount; /** * Размер ипотечной ставки */ private BigDecimal interestRate; /** * Срок кредитования */ private Integer period; /** * Список продавцов */ private ListSeller> sellers; /** * Список заявителей */ private ListApplicant> applicants; /** * Объект недвижимости */ private Realty realty; public Product getProduct()  return product; > public void setProduct(Product product)  this.product = product; > public BigDecimal getAmount()  return amount; > //. геттеры и сеттеры для полей public Realty getRealty()  return realty; > public void setRealty(Realty realty)  this.realty = realty; > >

DTO

Также в приложениях выделяют сущности DTO (Data-transfer object).

Data Transfer Object (DTO) — один из шаблонов проектирования, который используется для передачи данных между подсистемами приложения.

Технически, это то же самое, что и Entity, но с точки зрения бизнес-домена, эти объекты никак не связаны с ней.

Например, несколько полей, объединенных в одну сущность (DTO) для отправки в сервис расчета графика платежей. Пример:

package ru.bank.abc.dto; /** * Запрос для расчета графика платежей */ public class PaymentScheduleCalculationRequest  /** * Размер заемных средств */ private BigDecimal amount; /** * Размер ипотечной ставки */ private BigDecimal interestRate; /** * Срок кредитования */ private Integer period; public BigDecimal getAmount()  return amount; > public void setAmount(BigDecimal amount)  this.amount = amount; > public BigDecimal getInterestRate()  return interestRate; > public void setInterestRate(BigDecimal interestRate)  this.interestRate = interestRate; > public Integer getPeriod()  return period; > public void setPeriod(Integer period)  this.period = period; > >

Также DTO могут использоваться для слоя отображения.
То есть, это сущность, которая будет возвращаться пользователю в браузер (или в любое другое приложение-клиент) для отображения.

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

Например, если пользователь открыл форму для просмотра данных об участниках сделки, нет необходимости возвращать всю сущность ипотеки целиком, достаточно лишь вернуть DTO сущность, содержащую поля со списками продавцов List sellers и заявителей List applicants .

Service

Какие же сущности отвечают за выполнение бизнес логики в нашем приложении?

Такие классы именуются как Service (Сервис).

Service — класс, который отвечает за бизнес-логику при работе с конкретным Entity или DTO.

Как правило для каждой сущности Entity создается свой Service.
Через него может проходить логика создания\получения\обновления\удаления сущностей (CRUD операции), если такая предусмотрена в приложении.

Например для сущности Mortgage это будет MortgageService .
Он будет содержать CRUD методы, в рамках которых может выполняться дополнительная логика, например проверка корректности данных при создании нового ипотечного займа.

С уровня Service мы также можем обращаться к другим классам Service уровня.

Например при создании новой сущности Mortgage у нас возникает необходимость в расчете процентной ставки BigDecimal interestRate .
Для этого мы должны обратиться из класса MortgageService в другой класс-сервис — ExternalEvaluationService который в свою очередь сформирует специальную DTO, которую отправит (через сеть) в совершенно другое приложение, которое произведет расчет и вернет нам обратно результат через ExternalEvaluationService в MortgageService и который мы запишем в нашу сущность Mortgage в поле BigDecimal interestRate .

public interface MortgageService  boolean isUserFits(User user); boolean createMortgageRequest(Mortgage mortgage); Mortgage changeRate(Mortgage old); >

Repository (DAO)

Также с уровня Service мы можем обращаться на уровень Repository (Репозиторий).
Данный слой необходим для того, чтобы сохранять в базу или получать из базы какие-либо данные.

Repository — класс, который взаимодействует с каким-либо физическим хранилищем (например База данных) для наших объектов.

Здесь опять же используется аналогичный подход — для каждой сущности Entity создается свой Repository.

Например для сущности Mortgage это будет MortgageRepository .

В чем же разница? Приведем пример из реальной жизни: мы пришли в банк и хотим положить 10 рублей на наш счет. Мы подходим к кассе и говорим операционисту наш счет, ФИО и деньги. Она пересчитывает деньги, сверяет данные и кладет деньги в кассу. С точки зрения бизнесс-домена, оператор это сервис, а касса, с которой она взаимодействует это репозиторий. Заметим следующие особенности:

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

Так

Важно понимать, что при переносе такой модели в программный код, все реалзации классов должны лежать в своих пакетах, которые соответствуют их сущности: entity , dto , service , repostory . Например:

Иногда слой хранения данных делят на 2 паттерна:

DAO (Data Access Object)
рассмотренный выше Repository

Они оба отвечают за взаимодействие с каким-то хранилищем сущностей. В чем же тогда заключается разница между ними?

Представим ситуацию, что мы реализуем хранение сущности User . В случае с UserRepository у нас был бы следующий интерфейс:

public interface UserRepository  User get(String userName); void create(User user); void update(User user); void delete(String userName); ListUser> query(UserSpecification specification); // Один метод что правит всеми запросами поиска >

А в случае с UserDAO такой:

public interface UserDAO  void create(User user); void update(User user); void delete(User user); ListUser> getUserByLastName(String lastName); User getUserByAgeRange(int minAge, int maxAge); // Еще миллион методов поиска с разными параметрами >

Наверное, вы уже уловили суть. Самое главное отличие Repository от DAO в том, что он инкапсулируют всевозможные варианты поиска сущности в какой-то объект UserSpecification. В нем могут содержаться различные комбинации полей, по которым идет поиск, сколько страниц сущностей мы хотим увидеть и в каком порядке (сортировка).

Так

В общем случае наша программа будет выглядеть следующим образом (Разве что у нас нет базы данных):

Чистый код

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

Принцип S.O.L.I.D.

Принцип S.O.L.I.D. — это акроним из 5 основных принципов проектирования программ:

Single Responsibility (Принцип единственной ответственности ) — Каждый класс должен иметь одну и только одну причину для изменений. С нарушением SRP система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект «снежного кома», затрагивающего другие компоненты системы.
Open Closed Principle (Принцип открытости/закрытости) — Программные сущности должны быть:
- открыты для расширения(наследования)
- закрыты для изменения
  Идея в том, что однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса. Этот новый класс может переиспользовать код исходного класса через механизм наследования. Производный подкласс может реализовывать или не реализовывать интерфейс исходного класса.
Liskov Substitution Principle (Принцип подстановки Барбары Лисков) — объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Проще говоря, если у вас в проекте повсеместно используется экземпляры класса Collection , то вы вольны заменить их на List , Set или Queue .
Interface Segregation Principle (Принцип разделения интерфейса) — много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.
Dependency Inversion Principle (Принцип инверсии зависимостей) — Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Сюда входя следующие кейсы:
- Все типы переменных должны быть объявлены интерфейсом или абстрактным классом.
- Все классы должны быть зависимыми только от интерфейсов других классов. ? Все инициализации переменных должны происходить через паттерн Inversion of Control — например с помощью Factory method или механизмом Dependency injection

Принцип DRY

Принцип, нацеленный на снижение повторения информации различного рода. Нацелен на уменьшение кода и упрошения связей между сущностями.

Принцип YAGNI

Принцип, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности. Цель этого принципа в уменьшении количества фич, и, как следствие, количества кода, модулей и зависимостей.

Принцип KISS

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

Основные материалы

Видео: Learn — Clean Code
Стиль кода Java
Три ключевых принципа ПО, которые вы должны понимать

Дополнительные материалы

Stackoverflow: DTO vs entity
Stackoverflow: Repository vs service
Habr: DAO vs Repository
Книга: Роберт Мартин — Чистый код

Вопросы для самоконтроля

Java Program Structure

Что такое Entity?
Что такое DTO? Как расшифровывается?
В чем разница между Entity и DTO?
За что отвечает слой Service?
За что отвечает слой Repository?
Для чего нужно делить наше приложение на слои?

Java — Programming Principles

Что такое принцип DRY? Как вы его понимаете?
Что такое принцип KISS? Как вы его понимаете?
Что такое принцип YAGNI? Как вы его понимаете?
Что такое SOLID? Из каких составляющих принципов он состоит?
Приведите пример нарушения принципа Liskov Substitution
В чем основная цель приципа Dependency Inversion ?

Developed by Timur Sokolov and Ilia Isakhin.

We believe that knowledge is the most powerful tool you can use to change your life for better.

Зачем и как использовать Объекты передачи данных в Laravel

Data Transfer Object (Объект передачи данных) — паттерн программирования, который, при правильном использовании, может улучшить качество код и удобство его дальнейшего сопровождения. В этой статье мы узнаем, почему нужно использовать DTO и как это сделать в Laravel.

Что такое объект передачи данных?

Объект передачи данных (DTO) используется для передачи данных между уровнями приложения. Это простой объект, который содержит набор данных, обычно в форме свойств или полей, которые представляют определенный объект или концепцию в системе. Основная цель DTO — отделить различные уровни или компоненты, позволяя им взаимодействовать и обмениваться данными без необходимости знать детали реализации друг друга.

Зачем использовать DTO

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

Допустим, у меня есть такой код:

class UserController extends Controller < public function store(Request $request): JsonResponse < return response()->json([ $this->service->createUser($request->all()), Response::HTTP_CREATED ]); > >

И мне нужно изменить метод createUser . Это, в целом, довольно простой код, но если бы я его создавал год назад, то и не вспомнил бы какие данные возвращает метод $request->all() .

Я мог бы отрефакторить всё это через класс Custom Request :

class UserController extends Controller < public function store(CreateUserRequest $request): JsonResponse < return response()->json([ $this->service->createUser($request->validated()), Response::HTTP_CREATED ]); > >

Но теперь возникают две другие проблемы:
— валидация теперь связана с HTTP-запросом. Если мне нужно вызвать метод createUser , то мне нужно будет снова вручную провалидировать данные.
— данные маппированы, но поскольку $request->validated() возвращает массив, то не получится принудительно указать тип данных, передаваемых методу createUser .

Если мы применим здесь паттерн DTO, то сможем решить обе вышеописанные проблемы. Будем маппировать и валидировать данные в DTO. И теперь, при вызове метода createUser откуда либо, валидация будет произведена автоматически, нужно просто передать DTO в метод.

Как использовать DTO

Как объяснялось выше, DTO могут быть простыми объектами для маппирования свойств. Таким образом, самой простой реализацией DTO было бы создание следующего класса:

class CreateUserDTO < public function __construct( private string $name, private string $email, private string $username, private string $password ) <>// Add getters, setters, validation >

Затем создаём свой DTO из Request :

class UserController extends Controller < public function store(Request $request): JsonResponse < return response()->json([ $this->service->createUser(new CreateUserDTO(. $request->all())), Response::HTTP_CREATED ]); > >

В new CreateUserDTO(. $request->all()) мы используем именованные аргументы из PHP 8 для создания экземпляра CreateUserDTO .

Таким образом, мы решаем проблемы, которые мы подробно описали в предыдущем разделе. Теперь у нас качественный код и его легко поддерживать.

Заключение

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

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

Наш Телеграм-канал — следите за новостями о Laravel.

Задать вопросы по урокам можно на нашем форуме.

Читать:

Как натянуть сайт на wordpress