День 1897. #ЗаметкиНаПолях
5 правил для DTO
DTO — это объект передачи данных (Data Transfer Object). Его задача — передавать данные, и его можно использовать как для отправки данных, так и для их получения.

Часто передаваемые данные используют разные типы (возможно, даже разные языки программирования и стеки технологий) на каждом конце передачи. Единственное, на что вы можете рассчитывать при передаче – это данные и ничего больше. Они должны легко сериализовываться и десериализовываться в JSON, XML и т.п. Поведение сложно будет десериализовать на принимающей стороне. Отсюда первое правило для DTO.

Правило 1. DTO должны содержать только данные. Никакой логики и поведения.

С DTO должно быть очень легко работать, а также создавать их. Они не получают выгоды от инкапсуляции, и, как правило, им также следует избегать использования наследования (сокрытие вещей - это не то, что мы хотим с помощью DTO, а повторное использование типов в этом случае переоценено). В качестве DTO в .NET часто используют записи.

Правило 2. DTO не обеспечивают инкапсуляцию. Им не нужны приватные/защищённые члены.

Даже несмотря на то, что DTO не нуждаются в инкапсуляции, обычно предпочитают использовать свойства C#, а не поля. По умолчанию сериализаторы и другие функции языка работают со свойствами, а не с полями (хотя вы можете это настроить).

Правило 3. DTO должны использовать свойства (а не поля).

Очевидным соглашением об именах является простое добавление «DTO» (или «Dto») в конец имени объекта. Хотя это работает и подходит для самого простого представления, во многих случаях вам следует использовать более описательное имя.

Многие распространённые типы, используемые в современных приложениях .NET, могут (и обычно должны) создаваться как DTO. К ним относятся объекты запросов и ответов API, команды и запросы в CQ(R)S, события и многое другое. В таких случаях добавьте к типу более конкретное имя (например, «CreateUserRequest» вместо просто «UserDTO»).

Правило 4. DTO следует использовать суффикс «-DTO» только в крайнем случае. Предпочитайте более описательные имена.

Некоторые объекты в приложении должны быть DTO и называться в соответствии с их конкретным использованием, а не «FooDTO».

Правило 5. Следующие модели должны быть спроектированы как DTO:
- типы запросов/ответов API,
- модели представления в MVC,
- объекты результатов запроса к БД,
- сообщения (команды, события и запросы).

Для валидации свойств DTO вы можете использовать аннотации данных, IValidatableObject, FluentValidation или ключевое слово required.

Источник: https://ardalis.com/5-rules-dtos/

См. также:
- В чём разница между DTO и POCO?
- Ваш API и Модели Представления не Должны Использовать Модели Домена