Специализация
Python Backend Developer
Java Backend Developer
Node.js Backend Developer
Golang Backend Developer
React Frontend Developer
Выберите навыки
React
JavaScript
Git
Redux
Webpack
Сложность
1-3
4-6
7-8
9-10
Рейтинг вопросов
1
2
3
4
5
Подпишись на React Developer в телеграм
Использование DTO вместо сущностей
DTO защищают от:
Нечаянного изменения БД при обновлении сущности.
Утечки конфиденциальных данных (например, паролей).
Проблем ленивой загрузки (LazyInitializationException).
Почему не рекомендуется смешивать ORM-модели и DTO (request/response схемы) в одном файле?
ORM-модели и DTO решают разные задачи и живут в разных слоях приложения. ORM описывает структуру хранения данных в БД, а DTO — формат входящих и исходящих данных API. Если смешивать их в одном файле, код становится хрупким и трудноизменяемым. Любое изменение API начинает влиять на слой хранения данных и наоборот.
Single Responsibility Principle — как определить, что класс нарушает принцип единственной ответственности (количество методов, разные DTO на выходе)?
Класс нарушает SRP, когда он выполняет несколько несвязанных задач или отвечает за несколько аспектов системы. Признаки нарушения включают большое количество методов, разные типы DTO на выходе, частые изменения по разным причинам. Если класс меняется из-за изменений в разных бизнес-процессах или его методы работают с разными данными — это явный сигнал о нарушении принципа.
Почему нельзя прокидывать одну и ту же DTO через все слои, и как разделять модели?
DTO служит транспортом для API, доменная модель — для бизнес-логики, модель хранения — для БД. Их цели различны; смешение ведёт к хрупкости. Делайте явный маппинг между слоями.
Как лучше организовать структуру DTO для request и response моделей?
Request и response DTO лучше разделять явно, даже если их поля частично совпадают. Это позволяет независимо развивать входные и выходные контракты. DTO стоит группировать по доменам и операциям, а не по типу данных. Такой подход упрощает поддержку, версионирование и документацию API.
Объясните назначение DTO (Data Transfer Objects) в NestJS.
Что такое оператор $addToSet в MongoDB и чем он отличается от $push?
Как следует поступать с полями в DTO, которые рассчитываются на лету на фронтенде или не хранятся напрямую в базе данных?
Рейтинг:
1
Сложность:
4
DTO в NestJS — это объекты, которые описывают структуру данных, передаваемых в запросах и ответах. Они помогают валидировать данные, предоставляют типизацию и могут быть использованы для автоматической генерации документации API.
Рейтинг:
2
Сложность:
7
Оператор $addToSet добавляет значение в массив, только если его нет в этом массиве, предотвращая дубли. В отличие от него, оператор $push добавляет элемент в массив без проверки на дубли.
Рейтинг:
4
Сложность:
5
Вычисляемые поля следует включать в DTO, если они нужны клиенту, но не включать в модели базы данных. Расчет может выполняться на бэкенде перед отправкой DTO или на фронтенде после получения данных. Критерии выбора: сложность расчета, производительность, консистентность данных и требования клиента. Документировать такие поля как вычисляемые.
Рейтинг:
2
Сложность:
5
Рейтинг:
4
Сложность:
5
Рейтинг:
3
Сложность:
6
Рейтинг:
2
Сложность:
8
Рейтинг:
4
Сложность:
6
