For Gilead, you don't need to inherit from their classes. Have your
model objects implement ILightEntity. It's basically a wrapper around
a simple hashmap to store the proxy information. Your service can
use the GileadRPCHelper directly.Take a look at the implementation
of PersistentRemoteService. Our projects are structured this way and
it works great.
One gotcha with Gilead. It seems to play well with either a servlet
container or JBOSS. We are using it with GlassFish and it took some
tweaking to get everything running.
On Aug 4, 10:33 am, javier jasand...@gmail.com wrote:
Hello folks:
I've posted this question to the Hibernate user's forum, but in the
absence of replies, I am posting it here as well, in the hopes that
some of you may shed some light. Please accept my apologies if this
is the second time you see this post.
I'm about to engage in an enterprise project whose front-end is to be
built with GWT. I've had some Hibernate experience from past projects
and really like the ORM mechanism used by Hibernate for marshalling/
unmarshalling from a database. Now, as some of you know, domain
entities need to be transferred over the wire for GWT's consumption:
entities that have been instrumented with persistence information will
fail at the client side, as GWT cannot handle these objects.
So I've done some research and I've come across two common solutions
to this problem:
1) Using a framework called Gilead;
2) Replicating the domain model hierarchy with a second class
hierarchy used exclusively for data transfer (aka Data Transfer
Objects representing the persistent domain objects).
None of these solutions are good in my current situation:
1) Gilead intrudes into the design of an application by forcing the
entities to inherit from “LightEntity” and forcing
RemoteServiceServlet descendants to extend “PersistentRemoteService”.
Our design cannot allow this, as both of these type of objects already
inherit from a different hierarchy.
2) Our domain model is composed of 30 classes, some of which have
quite a few getters/setters. Replicating this domain model sounds like
trip to maintenance nightmare street, not to mention the amount of
extra code that we'll need to map things back-and-forth.
So even though I know (from experience) that Hibernate will make me a
lot more productive accessing the database than the alternative (ie
hand-coding with JDBC), all this productivity goes down the drain if I
now have to deal with recreating the objects in order to properly talk
to the client layer.
So now my question is, can I get away with the following:
1) make every single persistent entity to always load everything
eagerly by default (ie lazy=”false”) and make lazy loading the
exception to the rule (ie when fetching lists of things);
2) use a stateless Session-per-request approach, so that every time I
need something from the db a brand new persistence context is
initialized.
I understand that I'll be giving up caching and hence, taking a
performance hit, what I'd like to know is, how bad is this hit? is
this an acceptable compromise in my case? Is this approach still
better than going back to manual JDBC days?
Please advise if this is a horrible approach and if there is something
I should know before I put a rope around my neck.
Thanks in advance for any ideas, comments or suggestions.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
