приложения должен быть свой? Чтобы при изменении на увроне hanler-ов, не пришлось менять бизнеслогику.
DTO - это то, как бизнес логика работает с внешними источниками (из-за буквы T - transport), грубо говоря если проект большой, то к гадалке не ходи - дели все данные на 3 типа: внешние, доменные,хранимые К примеру для работы с сущностью User - хорошо иметь UserDTO{} который умеет только в серилизацию/десеривлизацию/валидацию. User{} - доменная модель с которой совершаются бизнес-операции и UserRecord - прослойка которая используется для работы со средствами хранения.
для работы с сущностью не нужна никакая UserDTO потому что работа с сущностью: ограниченный перечень сценариев (бизнес-кейсов, они же use cases) соответветснно в каждый юзкейс зайдет своя дто, так называемая команда, которая вообще не соотвтетствует User у юзера есть статус, имя, емейл, дата регистрации, активен или нет, токены но в юзкейсе UserCreate придет не мифическая UserDTO, а UserCreateCommand (что по своей сути DTO) с полями только для этого кейса (name, password) в юзкейсе UserBlock придет не мифическая UserDTO, а UserBlockCommand (что по своей сути DTO) с полями только для этого кейса (userId)
Тебе не нужна, другим нужна
но так ты получишь высокую связанность, если через одну дто ходить будешь, а ведь дробление на слои и появление дто были обусловленны понижением оной значит те, кому она нужна — немного идиоты, тк делают то, от чего уходили
Звучит как крудильня, хотя не считая различий которые ты пытаешься подчеркнуть, пишете об одном же. Postgrest тогда уж можешь взять, если всё что делаешь это маппишь DTO на сущность. Выше верно написали, снаружи приходят команды с данными нужными для выполнения бизнес-операции, а не данные чтобы их можно было в сущность смаппить
читай внимательнее
Обсуждают сегодня