4

Currently I have one dao, that uses generic methods and hibernate criteria to perform nearly all my data access (I planned to subclass for the more complex things later), it looks like this :

public <T> List<T> getAll(final Class<T> type){
    final Session session = sessionFactory.getCurrentSession();
    final Criteria crit = session.createCriteria(type);
    return crit.list();
}

public <T> List<T> getFieldEq(final Class<T> type, final String propertyName, final Object value){
    final Session session = sessionFactory.getCurrentSession();
    final Criteria crit = session.createCriteria(type);
    crit.add(Restrictions.eq(propertyName, value));
    return crit.list();
}

However, HQL is preferable as it can optimized by the database/connection (i.e. parametrized queries), while the criteria api has to be evaluated at runtime, so Restrictions.eq("name", "NimChimpksy") is not error safe at all.

Should I keep the generic dao (it feels nice to have only one dao), or just implement a common interface and use hql in a separate dao for each of my domain objects.

NimChimpsky
  • 43,542
  • 55
  • 186
  • 295
  • There is no difference between HQL and Criteria regarding prepared statements. Both use prepared statements. I don't see how restriction is not error safe. – JB Nizet Feb 23 '12 at 10:08
  • @JBNizet becuase the restriction does not get evaluated till runtime, whereas hql gets checked when you deploy ? I am referring to another answer I got : http://stackoverflow.com/questions/9380883/hibernate-criteria-multiple-table-joins – NimChimpsky Feb 23 '12 at 10:12
  • HQL is also checked at runtime. Named queries are checked at deploy time, but that doesn't mean that they are correct. If you want to be error-safe, implement unit tests for your DAOs. Then, everything will be checked at build time. – JB Nizet Feb 23 '12 at 10:18
  • @JBNizet thanks, that was indeed my original plan. Is there no performance hit at all using criteria either then ? – NimChimpsky Feb 23 '12 at 10:20
  • You won't know without measuring. But the cost difference of constructing SQL between a named HQL query, a HQL query and a criteria query will be completely negligible compared to the cost of actually executing the request against the database. You're optimizing at the wrong place. – JB Nizet Feb 23 '12 at 10:24
  • http://stackoverflow.com/a/15002922/106261 – NimChimpsky Mar 07 '13 at 09:00

2 Answers2

3

Frankly speaking, I don't see any problem with your current approach, assuming your queries are this simple and straightforward.

Usually, at least in my team, the choice of using HQL vs Criteria is more of a "preference" thing. HQL looks more like SQL and you can write more compressed code. Criteria looks more OO for some developers.

In my case, I tend to use HQL because it allows me to write much shorter and cleaner code for complex queries (again, it's really a matter of preference, I believe). However, Criteria can be very useful too because it allows me to construct query conditions on the fly whole lot more easier than HQL, here's a very simple example:-

public void doIt(String s1, String s2, String s3){
    ...

    if (/*some s1 condition*/) {
        crit.add(Restrictions.eq("s1", s1));
    }

    if (/*some s2 condition*/) {
        crit.add(Restrictions.like("s2", s2 + "%"));
    }

    if (/*some s3 condition*/) {
        crit.add(Restrictions.ne("s3", s3));
    }

    return crit.list();
}

Imagine if you were to do something like this in HQL, you will have to dynamically construct the HQL query string on the fly, which can make the code a little nasty to read.

limc
  • 36,786
  • 19
  • 95
  • 142
0

I am using a static class for all my basic Hibernate get, save, update, delete operations and it works pretty well.

public static List getList(Class c, Session session)
{
    return session.createQuery("FROM " + c.getSimpleName()).list();
}
djmj
  • 5,266
  • 4
  • 47
  • 89