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.
