-->
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.  [ 15 posts ] 
Author Message
 Post subject: Generic DAO example
PostPosted: Thu Sep 08, 2005 10:08 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
I've posted an early example of the cleaned up generic DAO pattern on the blog: http://blog.hibernate.org/cgi-bin/blosx ... genericdao


Top
 Profile  
 
 Post subject: Exception Handling
PostPosted: Tue Sep 13, 2005 2:59 am 
Newbie

Joined: Tue Sep 06, 2005 2:34 am
Posts: 1
Hi Christiam,

This DAO layer looks great.
But i am slightly confused about exception handling, Since GenericHibernateDAO calls lot of methods (save(), update() etc. ) on Session instance, all these methods can throw HibernateException.

If exceptions are handled in HibernateFilter as RunTimeExceptions, then how web application will be able to send a customized error message to the front end web page.

Pls. clarify.

Regards
Tarun


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 13, 2005 3:05 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
I don't know, why would I need to send customized messages when a fatal exception occurs? The application is dead, all I need to do is present a suitable error page. You can also map exception class names to URLs in web.xml.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 2:34 am 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
I'm using this at work now and I'll pitch the whole thing in a meeting next week. Good job Christian. Care if I put a request in the JIRA for a <hbm2genericDAO> ?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 4:30 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
hbm2dao should have this method of generation as an option...

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 1:24 pm 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
Will anyone object if I make a jdk attribute for hbm2dao. "1.4" would spit out a modified version of Gavin's DAOs, "1.5" would produce the Generic stuff.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 1:29 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
dont think so ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 18, 2005 3:05 am 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
Mmm ... on second thought, that's not a good idea. An @jdk overlaps w/ @generics. Making hbm2dao fork (head/DAOs vs. GenericDAOs) on @generics isn't good either because there is plenty of 1.4 unfriendly stuff in the head/DAOs regardless.

Each method also results in a JNDI lookup for the sessionFactory - slow and not as flexible as the Session-constructor-injection trick. This and the EntityManager you get w/ head/DAOs + @ejb says it's apples and oranges (pardon American pun).

Christian's blog wrote:
You should never have to wrap and re-throw an unchecked exception in a DAO method, certainly not for logging


All the methods in the head/DAOs do this.

try {
sessionFactory.getCurrentSession().delete(persistentInstance);
log.debug("delete successful");
}
catch (RuntimeException re) {
log.error("delete failed", re);
throw re;
}


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 18, 2005 4:19 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
i will probably change usage of @generics to something like @jdk15 to make it detectable if one can use jdk 1.5 constructs/methods instead of just generics.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 26, 2005 7:32 pm 
Newbie

Joined: Mon Jun 06, 2005 11:21 pm
Posts: 10
Thank you very much for the work on DAOs. I'll be implementing something like that in my project straight off. I had a bit of a theoretical question, though.

It seems to me that state-management is a kind of "extralinguistic" behavior of a persistence framework. A developer, for example, wouldn't be able to tell just from looking at the DAO interfaces what was going on. By itself, that wouldn't be such a big drawback. A greater problem might be that when the controller code assumes that kind of behavior, creating stub implementations of the daos becomes much more difficult. Would it be worth it not to assume such behavior, in exchange for a few lines of code that effectively does nothing under some implementations? Is there a point to Dao classes that are abstract enough to be used by state managing persistence frameworks and those that don't (effectively nullifying all the wonderful features that come along with state management)?

Also, on a more mundane level, if the DaoFactory opens the transaction, where is the code for committing it. Let us say we are not using a filter or callback and we'd like to close the session ourselves. A call to HibernateUtil would break the layering. Should closeSession() wrapper methods be placed in the Daos or the DaoFactory?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 27, 2005 6:56 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
http://hibernate.org/42.html
http://hibernate.org/43.html


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 10, 2005 3:06 pm 
Newbie

Joined: Mon Nov 01, 2004 6:46 am
Posts: 6
I really like the generic dao pattern. I've just found the constructor (in the abstract base classes for EJB3/Hibernate) w/ the persistent class argument a little bit cumbersome. The concrete DAOs paramterize the generic base class with the "right" entity class already, so I had the idea to reuse this information.

My first thought was (example for GenericEjb3DAO)
Code:
public GenericEjb3DAO() {
    this.persistentClass = T.class;
}


which is not allowed. But some Java 1.5 generics reflection can help:

Code:
public GenericEjb3DAO() {
    this.persistentClass = (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
}


I think this is less verbose (and less boiler plate code to write) because it eleminates the constructor (calling "super(Entity.class)") in the implementations. What do you think?

Sebastian


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 10, 2005 4:12 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
Interesting, I thought generic type information is stripped out in compilation and you can't access it at runtime.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 10, 2005 5:01 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
its a folklore ;)

The compiled bytecode instructions does not know of the type information, but the reflection api knows about it per class. If it weren't there AnnotationBinder would not be very usefull.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 10, 2005 5:57 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
Ah well, didn't know about the signature stuff. Second half of this article: http://www-128.ibm.com/developerworks/j ... 11085.html


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

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.