views:

212

answers:

2

I have a java web application built on Stuts2/Google Guice/JPA. It uses hibernate as the JPA vendor. I would like to add support so it can be used on Google's App Engine. Of course I'm running into issues with the queries and mappings. Such as Many-to-Many and joins not being supported.

I'm trying to come up with the best solution for keeping my app able to be standalone. For example sin a tomcat/jetty on any database the JPA vendor supports or Google App Engine with datanucleus as the vendor.

One solution I thought of would be to use JPA for my standalone implementations and JDO for Google's App Engine. Obviously this would require me to annotate my model objects with both JPA and JDO annotations and to write another implementation for the DAO layer.

Are there any other good solutions that others have tried?

+1  A: 

You could relocate your queries to an XML configuration. This way you can have queries for a RDBMS in one configuration and your queries for BigTable in another configuration.

Another idea is that DataNucleus is a JPA vendor as well. You could probably ease your development by making it your primary JPA vendor on both GAE and your Servlet Container. JPA vendors often times have very slight differences between what they do with their metadata and this may save you some headaches.

Drew
What about handling the many-to-may annotations?
Ruggs
Unfortunately, GAE just can't handle Many-to-Many relations right now. The best you can do is to carry collections of the keys on each class and handle the collections in your DAO/Service layer. If you're good about only accessing things through the DAO/Service layer, rather than a lot of property access (`Service.getContactByCategory(category)` as opposed to `category.getContacts()`) then you should be able to re-impliment the DAO so that it loads the keys when you call.
Drew
This is an existing application, and using the service like you suggested is not an option. Either way I'd have to have a different implementation of the service, so it would be more than simply putting queries in different XML files.
Ruggs
+1  A: 

I think your approach is a good one. I think a well design architecture is the best approach. You will most likely see a lot of variance in the DAO layer. A good design would see a DAO interface, then each specific model access would have its own implementation of that interface e.g. JpaMyObjectDAO, JpaGAEObjectDAO etc. Also like you siad, App Engine has some special requirements when it comes to declaring your entity classes. Perhaps you could have different versions of the entity classes (each that conforms to its storage scheme like App Engine or Hibernate), then have a common DTO representation for your higher layers to use.

darren
I already have a good separation of DAO interfaces and service interfaces, so changing implementations is fairly easy. It's looking like that is the path I'm going to have to take. I'm still thinking about using DTO objects instead of my model objects. Right now I use the model objects all the way to the view.
Ruggs