views:

1547

answers:

5

What is the best persistence API for use with GWT?

Sadly, the application will be hosted on my own java server, as I will need more control than GAE will give me.

I know I will need to have two sets of my entities, one for the server side, and some pojo's for the client side. I'm looking to make the mapping of the data as simple as possible between the two, but these will be deeply nested objects so it has to be robust. I was looking at Dozer for my mapping needs.

Previously I've used EJB3 with TopLink, so that's very familiar to me, but I would like to get community input on what other API's work well with Dozer and GWT.

+1  A: 

For the configuration as described there is hardly any dependency between GWT and Persistence API/implementation. GWT-RPC with data object mapping should completely isolate you from the Persistence layer and API.

It sounds that driving forces for your choice should be Persistence implementation and mapping API features. If TopLink is familiar to you and it satisfies your requirements plus works with Dozer then it is a logical choice.

grigory
+1  A: 

Using something like EJB3 with Toplink/EclipseLink means you can send the one set of POJOs all the way between your back end and front end, eliminating any need for translation code. This means you don't have to worry about any sort of mapping at all. It's the solution we use on all our projects and it's great.

rustyshelf
Having persistent objects (graphs of objects) passed for GWT-RPC calls is against GWT best practices as described in this presentation: http://code.google.com/events/io/sessions/GoogleWebToolkitBestPractices.htmlDid you rely upon lazy initialization to trim the size of serialized objects passed?
grigory
No, I have a golden rule when working with JPA. When using lists in 99% of the cases children should link to their parents, and parents should not contain lists of their children. This is not just GWT related, if you have lists that contain lists that contain lists your JPA code will eventually die a horrible death. I know that they are all just pointers, but it will still fall over, trust me :)So to directly answer your question no, my code was designed so that it doesn't need trimming, no matter where it goes (GWT, Stripes, etc)
rustyshelf
It's a good rule and it works more like 80/20 for me. The other 20% percent benefit from more advanced JPA relationships and lazy initialization. But, of course, consistency matters most so if this rule works for you then it's a right rule for you. I like to be more flexible but careful.
grigory
+2  A: 

Take a look at hibernate4gwt which is a framework that effectively allows you to use your server side model objects on client side so you do not need to create separate dto's when sending the data between client and server side.

You do need to be careful though, you have to think carefully about lazy loading and cascading otherwise you could end up sending huge volumes of unnecessary data to the client side which is obviously not very efficient.

In short, I have used this for a small project, but it is not ideal for large, more complicated applications.

Clinton Bosch
that looks like a really nice framework. I love the idea of not having dto's. What's the reason this framework wouldn't be good for a large project?
KevMo
I found it to be a bit of a maintenance headache when the project became big and model objects were being loaded/persisted from multiple places in the application. Obviously you set up your model objects so that most fields are lazy loaded otherwise you end up sending huge volumes of unnecessary data to the client side, you end up having to really keep your wits about you when deciding which fields to load and what possible knock on effect that may have. By using dto's you can decide EXACTLY what data gets sent and optimise your dataflow, and for bigger projects this is crutial.
Clinton Bosch
+1  A: 

I use Ibatis all the time with GWT. theat means the there are no Lazy loading issues and i use the same set of entity beans on both the client and the server. The price i have to pay is having to create my tables on the database and also having to write sql scripts for my dao methods. Apparently this is a good thing for me as i want to be incharge of the database.

Joshua Kamau
A: 

We use hibernate Criteria queries in our daos which we use from our GWT services. Our criteria queries use projections. This means that Hibernate will load data and populate your dtos directly. This saves lots of boilerplate code.

I have a jira issue logged with hibernate to ask them to implement a new JSON EntityMode. Hibernate already has POJO, XML and Map modes. If we had JSON one, then hibernate would be able to emit and consume JSON objects just like it does pojos. This would be sooooo cool.

Kango_V