DTO часть концепции семейства POJO (старый добрый джава объект) POJO как супратив сложным Enerprise Object с кучей сложнйо логикой и супротив AR объектам (Active Record) про то, что состояние можно описать в простом объекте, под задачи... теперь о задачах: - есть сущности — бизнес-объекты состояния приложения, контролирующие свое состояние (ивнарианты) и имеющие персистенс идентификатор - value object — бизнес-объекты, которые олицетворяют некоторое значение и также контролируют свои инварианты/валидность, но им не требуется персистенс-идентификатор (например дата, деньги, валюта, id и прочие) - dto — объекты для обмена, по сути объектный вариант массива данных, который мы передаем, простые и тупые... передавать можем между слоями dto — концепция, по сути в вашем приложении в некоторых местах они могут называться не dto, а response/request — те же dto по своей сути и описываются именно этим определением, но названы более семантично в виду использования их на границе контроллеров как входные/выходные данные короче, dto — просто типизированные данные для передачи в/из куда либо dto отлично подходят и в кейсе read model — эти тоже dto, в них фетчим данные просто как для отображение UI
Максим, а можно ли сказать, что дто - тот же самый пакет models?
моделс это скорее ваши entity. То есть нельзя. dto не принадлежат к слоям бизнес логики они к слоям базы\апи принадлежат
можно с натяжкой при некоторых случаях — если у вас анемичные модели (без поведения и контроля стейта самим моделями), которые обмазаны тегами и метой для сериалзации и для гидрации в/из БД — то в некоторых кейсах (собственно в сериализации и гидрации) они будут и дто 🙂 а в случае с бизнесухой они будут модели побочка — высокий каплинг, высочайший
Я в симфони когда ещё на пыхе кодид городил отдельные ДТО из-за этого потому что был каплинг между БД, моделями и апи, а когда надо выдавать данные не так как они лежат в БД приходится делать промежуточные сущности
Навязывание ui логики на бизнес сущности часто приводит к этому: доктрина там или gorm или TypeORM — не важно
Обсуждают сегодня