Hi Jens, Thanks for the quick reply.
I have the creation of DTOs and the JPA query language in mind. Thanks for pointing out. Our DB-Accesses are very straight forward, so no really complex queries. Just one more thing... Why is it important to have one EntityManager instance per request? What would the consequences be? If I am only allowed to have one EntityManager from the top till deep down in the business logic maybe it would be better to write a servlet filter and keep the EntityManager as a ThreadLocal variable for this request... Greetings Stefan On 19 Sep., 12:26, Jens <jens.nehlme...@gmail.com> wrote: > Should work.. just make sure you only have one EntityManager instance per > request. I use a command pattern so I have one place where I can handle the > transaction (create transaction before command handler executes and commit > afterwards). But command pattern as well as DTO's leads to lots of classes > for a simple server request...don't know if I would choose it again > (command, command result, command handler, JPA entity, DTO class, possibly > DAO class). Also JPA's query language (JPQL) does not support everything > that native SQL supports so you have to keep that in mind (but sure you can > also execute native SQL queries with JPA if there is no other possibility). > > Currently I am looking into myBatis (http://www.mybatis.org/) for a new > projects. It uses native SQL and has some nice code generator support. Maybe > you should take a look at it, as you already have native SQL for a given > database. > > -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
