I'm going to start a project of a REST application managed with Spring and with Hibernate for my model.
I know that Spring allows you to get Java object from the HTTP Request (with @Consumes(JSON)
annotation). Is there any conflict if this Java object is also a Hibernate entities? And is nested object working (like @ManyToOne
relation)?
Yes, this wouldn't be a problem and is actually a fairly common practice.
In the recent years I have come to realize that sometimes, however, it is not a good idea to always build your views based on your domain directly. You can take a look at this post:
http://codebetter.com/jpboodhoo/2007/09/27/screen-bound-dto-s/
It is also known as "Presentation Model":
http://martinfowler.com/eaaDev/PresentationModel.html
The idea behind that is basically the following:
Imagine you have the domain entry User, who looks like that :
Let's now imagine you have a view where you wanna display that user's name, and you totally don't care about the permissions. If you use your approach of immediately returning the User to the view, Hibernate will make an additional join from the Permissions table because event though the permissions are lazily loaded by default, there is no easy way to signal to the jackson serializer or whatever you are using, that you don't care about them in this particular occasion, so jackson will try to unproxy them (if your transaction is still alive by the time your object is put for json serialization, otherwise you get a nasty exception). Yes, you can add a
@JsonIgnore
annotation on the permissions field, but then if you need it in some other view, you are screwed.That a very basic example, but you should get the idea that sometimes your domain model can't be immediately used to be returned to the presentation layer, due to both code maintainability and performance issues.
You can map the json request without using any library at REST web-services (Jersy)
this sample of code:
This hibernate entity called book:
This web-services function
This is sample json request:
}
We were using such approach to simplify design and get rid of many dtos (we were abusing them too much). Basically, it worked for us.
However, in our REST model we were trying to do not expose other relations for an object as you can always create another REST resources to access them.
So we just put
@JsonIgnore
annotations to relations mappings like@OneToMany
or@ManyToOne
making them transient.Another problem I see that if you still like to return these relations you would have to use
Join.FETCH
strategy for them or move transaction management higher so that transaction still exists when a response is serialized to JSON (Open Session In View Pattern). On my opinion these two solutions are not so good.As I explained in this article, it's very easy to persist JSON object using Hibernate.
I wrote an article about how you can map JSON objects on both PostgreSQL and MySQL.
For PostgreSQL, you need to send the JSON object in a binary form:
The
JsonBinarySqlTypeDescriptor
looks like this:and the
JsonTypeDescriptor
like this:Now, you need to declare the new type on either class level or in a package-info.java package-level descriptior:
And the entity mapping will look like this:
That's it!
Since you are just starting, perhaps you could use Spring Data REST?
This is the project: http://projects.spring.io/spring-data-rest/
And here are some simple examples:
As you can see in the examples, there are no extra DTOs beyond the @Entity annotated POJOs.