As a reminder for everyone reading this code. Do not do it like that.
Separate your DTO from your data base models (Entity) with an adapter (Repository) interface.
Entities are for abstracting your database away. DTO is for abstracting your business logic away.
Your services should bridge DTO and Entities where you can add business logic. Your Repository abstract your Entities from your database to allow you to use another library / database without rewriting all your business logic.
Hi! My name Antonio, for friends Tony, I'm Full Stack Software Developer - Open Source enthusiast, TS/JS enthusiast, NestJS Contributor, passionate about NestJS, Fastify, Angular and React/Next.js
Hi ecyrbe, i wrote it like this just to show how it works then to make it understand even by those coming from orm type as typeorm, however I agree with what you said too I use the pattern repository. I leave the freedom to anyone to make their own choices as it should be. 👍
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a reminder for everyone reading this code. Do not do it like that.
Separate your DTO from your data base models (Entity) with an adapter (Repository) interface.
Entities are for abstracting your database away. DTO is for abstracting your business logic away.
Your services should bridge DTO and Entities where you can add business logic. Your Repository abstract your Entities from your database to allow you to use another library / database without rewriting all your business logic.
Hi ecyrbe, i wrote it like this just to show how it works then to make it understand even by those coming from orm type as typeorm, however I agree with what you said too I use the pattern repository. I leave the freedom to anyone to make their own choices as it should be. 👍