Menu
I have a situation in which i can send JPA entity as rest request and/or get JPA entity as rest response
@RequestMapping(value = "/products", method = RequestMethod.POST)
public @ResponseBody ProductDetailsResponse createNewProduct(@RequestBody ProductDetails newProduct)
throws Exception {
ProductDetails is an entity
@Entity
@Table(name = "product")
public class ProductDetails {
Should I use this, or have some kind of transformation from entities to another kind of objects
646
Entities in JPA are nothing but POJOs representing data that can be persisted to the database. An entity represents a table stored in a database. Every instance of an entity represents a row in the table.
JPA needs a constructor and setter for each declared field. Does it mean we have to expose the default constructor and each setter ? JPA supports private constructor and private setters. This entity is a valid JPA entity and it can't be modified after its creation.
The JPA specification requires the @Entity annotation. It identifies a class as an entity class. You can use the name attribute of the @Entity annotation to define the name of the entity. It has to be unique for the persistence unit, and you use it to reference the entity in your JPQL queries.
3.1. There are several requirements that our entity class must fulfill, and the one we're most concerned with, according to the JPA specification, is: If an entity instance is to be passed by value as a detached object (e.g., through a remote interface), the entity class must implement the Serializable interface.
There is no hard and fast rule but its not considered a good practice ( for very good reasons & Its very opinionated view ) to use JPA entities as DTOs ( Data Transfer Objects ).
Other than DTOs being lightweight versions of entities in terms of size, there are other advantages too.
One such advantage that I realized is lighter versions of relationships too e.g. for a One - To - Many unidirectional relationship , your child entity will reference back your parent entity too but you can break that chain in DTOs so avoid lots of JSON conversion and infinite looping related issues.
I find doing JSON to Object conversions ( and vice versa ) at DTO level a bit easier than at entity level because entities represent DB diagram not client business diagram.
One simple generic utility class to do conversions ( from DTO to Entity and vice - versa ) will be enough. You can use model mapper API as described here .
I don't let entities cross service layer boundary, its all DTOs at controller and I do conversions at controller.
There are very interesting questions on SO on this topic that you can browse ,
Should I convert an entity to a DTO inside a Repository object and return it to the service layer?
Conversion of DTO to entity and vice-versa
REST API - DTOs or not?
Additional boiler plate code is one disadvantage of DTO approach.
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
