ИЧ
Entity описывает схему бд, интерфейс для модели нужен далеко не всегда, Dto на вход и на выход, если они отличаются от Entity, на мой взгляд так
т.е. внутри сервиса работать с DTO это нормальная практика?
Size: a a a
2020 August 13
I
т.е. внутри сервиса работать с DTO это нормальная практика?
Я не вижу проблем, смысл дто в передаче данных между слоями приложения
ИЧ
Я не вижу проблем, смысл дто в передаче данных между слоями приложения
понял, спасибо
GG
Entity описывает схему бд, интерфейс для модели нужен далеко не всегда, Dto на вход и на выход, если они отличаются от Entity, на мой взгляд так
Всегда на выход нужно делать dto, лучше не оголять entity
I
Всегда на выход нужно делать dto, лучше не оголять entity
Согласен 👌
ИЧ
Всегда на выход нужно делать dto, лучше не оголять entity
я про вот это, а не entity базы данных
https://docs.nestjs.com/techniques/serialization
https://docs.nestjs.com/techniques/serialization
ИЧ
или этот class-transformer именно к сущности бд и нужно подвязывать?
I
я про вот это, а не entity базы данных
https://docs.nestjs.com/techniques/serialization
https://docs.nestjs.com/techniques/serialization
Это и есть Dto, в примере называется entity вводит в заблуждение только
I
или этот class-transformer именно к сущности бд и нужно подвязывать?
из entity схемы трансформируй черед dto на выход
ИЧ
из entity схемы трансформируй черед dto на выход
ага, т.е. один dto с class-validator на вход и другой с class-transformer на выход?
I
ага, т.е. один dto с class-validator на вход и другой с class-transformer на выход?
Да
🏡K
немного запутался в изучении неста, поправьте пж где я не прав
в контроллере на вход от пользователя мы принимаем DTO для валидации, далее сервис уже работает с интерфейсом и когда сущность нужно вернуть пользователю мы создаем Entity для сериализации
т.е. DTO это только то что идет на вход, внутри приложения используем interface, а перед выдачей пользователю преобразовываем объект в Entity использующий class-transformer?
учитывая что еще отдельно entity/schema для бд, то получается аж 4 файла описывающих одну и ту же сущность
как с этим жить?
в контроллере на вход от пользователя мы принимаем DTO для валидации, далее сервис уже работает с интерфейсом и когда сущность нужно вернуть пользователю мы создаем Entity для сериализации
т.е. DTO это только то что идет на вход, внутри приложения используем interface, а перед выдачей пользователю преобразовываем объект в Entity использующий class-transformer?
учитывая что еще отдельно entity/schema для бд, то получается аж 4 файла описывающих одну и ту же сущность
как с этим жить?
Их дофига потом станет) нужно не просто такой же класс с такими же полями делать а типизации оригинала юзать и типы полей оригинала
class SignInDto implements Omit<User Entity, 'username'|'password'>{
username:string;
password:string;
}
class SignInDto implements Omit<User Entity, 'username'|'password'>{
username:string;
password:string;
}
🏡K
Если проперти ентити сменит тип у тя ругнется
🏡K
В сервиса в аргументах вот так
deleteUser(id: UserEntity['id']){}
deleteUser(id: UserEntity['id']){}
🏡K
Если слой слой с дто не знает про ентити и слой работы с базой, то тогда через диай делаешь сервис на уровне приложения и указываешь типы, имплементс сервис где есть дто, а в аргументах указываешь типы слоя с базой, и так типизации сохранится
🏡K
В этом случае не нужно женериковые сервисы делать иначе перебьешь типы слоя с ентити и все разьедится
BO
Привет) Если есть кто, например, из мира Rails, знают что такое Service Objects - грубо говоря подход, в котором операции, которые сложнее простого обновления записи в контроллере, выносятся в отдельные классы. Теперь к несту - у меня в приложении, есть генерация огромного отчета с огромной кучей кода и логики. Хочется это разбить, но какой подход применять? Есть бест практис? Во что это выносить? Куда это выносить?)
VT
Привет) Если есть кто, например, из мира Rails, знают что такое Service Objects - грубо говоря подход, в котором операции, которые сложнее простого обновления записи в контроллере, выносятся в отдельные классы. Теперь к несту - у меня в приложении, есть генерация огромного отчета с огромной кучей кода и логики. Хочется это разбить, но какой подход применять? Есть бест практис? Во что это выносить? Куда это выносить?)
присоединяюсь к вопросу, тоже интересно
GS
Привет) Если есть кто, например, из мира Rails, знают что такое Service Objects - грубо говоря подход, в котором операции, которые сложнее простого обновления записи в контроллере, выносятся в отдельные классы. Теперь к несту - у меня в приложении, есть генерация огромного отчета с огромной кучей кода и логики. Хочется это разбить, но какой подход применять? Есть бест практис? Во что это выносить? Куда это выносить?)
Не знаком с rails, но звучит так, будто это просто бизнес-логика и можно вынести в обычный ES модуль, либо nest сервис.
GS
Смотря с чем этот кусок кода связан и как