Providing JPA Objects Through a Service

Question

We are in the process of developing a web application with AngularJS, Rest, JPA. I read several articles on how domain objects should not be exposed through services. I understand that this is a tight connection, there may be circular links, separation of problems and it seems to me. But then I see articles about applying both jpa and jaxb mappings to the same model, for example, eclipseLink moxy.

Then there is data REST, which exposes jpa objects via rest api. (Maybe Spring Data REST is used to solve another problem)

So, I'm a little confused. Answers to the following 2 questions and scenarios where better than the other will be useful.

• What are the benefits of applying jaxb and JPA annotations to the same domain model? Is this done only in the first place to avoid DTO between layers?

• Should Spring REST data be used only if you are developing an application that needs to expose CRUD operations and there really are no other business functions?

Answer 1

Using DTOs requires certain overhead: DTO classes must be created; feature classes must be mapped to DTO before serialization.

The DTO also “doesn't feel right” because they seem to contradict the “don't repeat yourself” principle. Frustrate a look at the essence and DTO and see that they are essentially the same.

Thus, direct disclosure of your JPA entities reduces code and reduces mental overhead when working with code. Your controllers, services, and repositories are dealing with the same classes.

However, there are problems:

• The mismatch between your internal views and the interface that you want to provide the user with an API.

  Real-world example: hierarchical documents in which the root document is article and the child documents are sections . Internally, each document relates to a parent document, which may be null.

  Exposing this object directly through the REST interface will require the client to send an id (or url to HATEOAS) as part of its sent object in order to correctly link documents.

  It is much better for the api user POI to be /articles/{id}/sections/ when creating the subsection.

• Providing internal data.

  Your objects may include identifiers, disk paths, etc. that are not intended for public consumption. You will have @JsonIgnore them when serializing. When deserializing, you can also fill them out of the object manually.

• Performance.

  As above; perhaps your entity contains a large data object. You want users to be able to perform POST or PUT, but they do not need to load the object in order to read other fields of the object.

• Possible problems with serialization.

  In this case, the classic crash cases are collections with lazy downloads.

• More complex serialized views than necessary.

  Real world example: a word object with a set of synonyms ; synonyms depend on the word. Direct serialization of objects will result in:

   { "id":12, "word": "cat", "synonyms": [ { "id": 23, "synonym": "kitty" }, { "id": 34, "synonym": "pussycat" } ] } 

  The best model:

   { "word": "cat", "synonyms": [ "kitty", "pussycat" ] } 

• Many annotations in one class that can reduce clarity.

  Depending on the complexity of your entity, you may have JPA annotations ( @Entity , @Id , @GeneratedValue , @Column , @ManyToMany , @MappedBy , etc.), XML annotations ( @XmlRootElement , @XmlType , @XmlElement , etc. etc.), JSON annotations ( @JsonInclude , @JsonIgnore , @JsonProperty , etc.) and validation annotations ( @NotNull , @Null , etc.) are all in one class.

Because of all these issues, I usually use DTO. I am making an entity to map the DTO manually, but there is a project that is trying to make this simpler, like Dozer .

I can imagine using spring-data-rest or directly exposing my entities only when I have very simple entities, without too many relationships between them, and where there is a high correspondence between the entity model and the model that I wanted to provide the user.