-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Hibernate, GWT & eagerly fetching
PostPosted: Fri Jul 31, 2009 8:50 pm 
Newbie

Joined: Wed Jun 17, 2009 11:08 am
Posts: 7
Hello folks:

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.