✅ Finding Data with SPRING DATA: th-cam.com/video/EsO8NPorfZ8/w-d-xo.html ✅ DTOs are the "M" in MVC. But what is MVC? th-cam.com/video/_umhGrMyAyQ/w-d-xo.html ✅ Want a deeper dive into the world of DTOs? th-cam.com/video/cxVHPXVI7KA/w-d-xo.html
Additionally, it may be beneficial to separate database entities from domain data (i.e., source/db entities, domain entities, and DTOs), which can further decouple data fetching and representation: - DB/Data Source Entities: Represent data directly from the source, without necessarily being structured as classes if they can be mapped directly to domain objects. - Domain Data: Describes the core information about an entity (what the platform knows about the entity), abstracted from its source or storage format. - DTO (Data Transfer Object): An API layer mapped from Domain Data, designed to support versioning. This separation can make the system more modular and adaptable to changes in data sources or API structures.
Would you call the concept of a wrapper/container class a DTO? I’ve been pushing on my team at work to use wrappers! Hypothetically, if an endpoint just returns a list of users, instead of ResponseEntity I’ve told the team to make a UserResponse class with a single field of List of Users! In my head if we need to modify the structure of the endpoint, I’d rather just tack on a new field to the wrapper class than to have a breaking change to the endpoint! Would love to know thoughts on this 😄 Same thing for Batch jobs, I’ll define a wrapper class to hold data that the reader passes to the processor and so on, for the same reasons
Since you have a custom type used to represent the end product on the web, I’d say yes. You could adjust this type in the future as needed to either add fields or alter the presentation using Jackson annotations. You can ignore other fields using these same annotations. And since none of them impact the way the User data is stored in the database you have that decoupled. Now if you needed to apply such annotations to the User type itself; you might need some UserDto as well somewhere in the future but that is pretty to encapsulate in your response DTO. But overall having this class for responses is a solid move.
Depends on where we’re talking about validation. If you mean JSR 303 type validation, it can really be on any class. Though if you’re using DTOs for the web later it would be preferable there so it fails sooner rather than later. Personally, I prefer putting validation checks in either the constructor or the setters. That way; the class validates whether it not bean validators are bootstrapped or not. And this approach is quite easy to unit test.
✅ Finding Data with SPRING DATA: th-cam.com/video/EsO8NPorfZ8/w-d-xo.html
✅ DTOs are the "M" in MVC. But what is MVC? th-cam.com/video/_umhGrMyAyQ/w-d-xo.html
✅ Want a deeper dive into the world of DTOs? th-cam.com/video/cxVHPXVI7KA/w-d-xo.html
Additionally, it may be beneficial to separate database entities from domain data (i.e., source/db entities, domain entities, and DTOs), which can further decouple data fetching and representation:
- DB/Data Source Entities: Represent data directly from the source, without necessarily being structured as classes if they can be mapped directly to domain objects.
- Domain Data: Describes the core information about an entity (what the platform knows about the entity), abstracted from its source or storage format.
- DTO (Data Transfer Object): An API layer mapped from Domain Data, designed to support versioning.
This separation can make the system more modular and adaptable to changes in data sources or API structures.
In regards with hexagonal architecture there's a book I recommend "Get your hands dirty on clean architecture by Tom Hombergs"
Thank you so much for this well explained video.
Be sure your subscribed. The new season of the Pro Coder Show is launching at the end of the month!
Would you call the concept of a wrapper/container class a DTO?
I’ve been pushing on my team at work to use wrappers! Hypothetically, if an endpoint just returns a list of users, instead of ResponseEntity I’ve told the team to make a UserResponse class with a single field of List of Users! In my head if we need to modify the structure of the endpoint, I’d rather just tack on a new field to the wrapper class than to have a breaking change to the endpoint! Would love to know thoughts on this 😄
Same thing for Batch jobs, I’ll define a wrapper class to hold data that the reader passes to the processor and so on, for the same reasons
Since you have a custom type used to represent the end product on the web, I’d say yes. You could adjust this type in the future as needed to either add fields or alter the presentation using Jackson annotations. You can ignore other fields using these same annotations. And since none of them impact the way the User data is stored in the database you have that decoupled. Now if you needed to apply such annotations to the User type itself; you might need some UserDto as well somewhere in the future but that is pretty to encapsulate in your response DTO. But overall having this class for responses is a solid move.
Records in Java are a great newish alternative instead of using DTOs
banger!
Hi, what about validation? can I do the validation on the entity or do I have to create a dto for this purpose ?
Depends on where we’re talking about validation. If you mean JSR 303 type validation, it can really be on any class. Though if you’re using DTOs for the web later it would be preferable there so it fails sooner rather than later. Personally, I prefer putting validation checks in either the constructor or the setters. That way; the class validates whether it not bean validators are bootstrapped or not. And this approach is quite easy to unit test.
Well, hexagons are the bestagons :D
Hah.
Hi Greg! thank you for the advice about this topic. By the way I like your haircut and it seems that you have lost some weight, you look great.
Thanks!!