tag:blogger.com,1999:blog-22587889.post114440782987288945..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Java Persistence - Fun with Generic DAOsAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-22587889.post-42809223103904752822007-08-01T13:14:00.000+05:302007-08-01T13:14:00.000+05:30@Daniel: I was mainly using this idiom for native ...<I>@Daniel:</I> I was mainly using this idiom for native JDBC based DAOs. But I find that u r using Hibernate as the ORM framework. Do u still want to use joins in SQLs ? I think having a rich domain model and ORM based associations will be a better approach. And Hibernate offers lots of features on this. A very useful pattern to use in this modeling is the Repository pattern of Eric Evans as mentioned in his DDD book. Sometime back I had <A HREF="http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html" REL="nofollow">blogged</A> <A HREF="http://debasishg.blogspot.com/2007/02/domain-driven-design-use-orm-backed.html" REL="nofollow">on</A> using the Repository instead of the DAOs as a domain level abstraction. Have a look at these posts - I am sure u will find them useful. They talk about generic Repository design instead of generic DAO design. Also have a look at Chris Richardson's <A HREF="http://chris-richardson.blog-city.com/customizable_convention_over_configuration_with_arid_pojos.htm" REL="nofollow">blog entry</A> on generic DAOs. He offers a very elegant solution using Spring.<BR/><BR/>Regarding the codebase, I have to dig it out, since it has been quite some time since I wrote them. But I would strongly recommend u to use domain model associations and hibernate mapping leaving the joins to the underlying ORM engine. Mine was one meant to be used for native JDBC based DAO abstractions.<BR/><BR/>Cheers.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-46374800173302562062007-08-01T01:37:00.000+05:302007-08-01T01:37:00.000+05:30Are you still using this idiom? If so would you b...Are you still using this idiom? If so would you be willing to share the code? I'm interested in creating a generic dao framework that could be used with any engine ie Hibernate, Torque, etc. And the main point of interest for me right now if the joining of multiple tables.Xanthroshttps://www.blogger.com/profile/09828388591605235006noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-1148146385662223652006-05-20T23:03:00.000+05:302006-05-20T23:03:00.000+05:30Very interesting. I mostly use Hibernate for my OR...Very interesting. I mostly use Hibernate for my ORM and Spring as the wiring, so its useful to have a generic base Dao class, with methods that basically delegate to the underlying HibernateTemplate object, so I was familiar with the idea of a generic base Dao class. Something like this:<BR/><BR/>BaseDao<T> {<BR/> get(Class clazz, Serializable id) : T {<BR/> return getHibernateTemplate().get(clazz, id);<BR/> }<BR/> ...<BR/>}<BR/><BR/>Your ICriteria implementation is very similar to the Hibernate Criteria implementation, so I guess you are on to something here (great minds think alike) :-).<BR/><BR/>One thing I have never thought of before is how you extended the Dao concept to include Projections and Joins. And yes, when you think about it, it makes so much sense.<BR/><BR/>Keep up the great work!Sujit Palhttps://www.blogger.com/profile/06835223352394332155noreply@blogger.com