I've posted an early example of the cleaned up generic DAO pattern on the blog: http://blog.hibernate.org/cgi-bin/blosx ... genericdao

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

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.

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> ?

hbm2dao should have this method of generation as an option...

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.

dont think so ;)

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).



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;
}

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.

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?

http://hibernate.org/42.html
http://hibernate.org/43.html

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)


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



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

Interesting, I thought generic type information is stripped out in compilation and you can't access it at runtime.

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.

Ah well, didn't know about the signature stuff. Second half of this article: http://www-128.ibm.com/developerworks/j ... 11085.html