小谈Hibernate中的HQL与QBC查询

小谈Hibernate中的HQL与QBC查询

    最早接触Hibernate是在2004年，当时怀着忐忑和不安的心情来学习这门技术。经过这几年的使用和研究，也积累了一定的经验，下面就HQL和QBC查询来谈一下我从工作中得到的一些总结。
    本文不会讲什么是Hibernate、什么是ORM、更不会谈怎样使用HQL与QBC。本文的目的是让大家对平常使用最多，也是最广泛的与数据库打交道的两种方式，有一个新的认识。
    恩，如果你还不知道Hibernate，大象建议你先去学一下再来看本文，如果你已经是这方面的高手，大可以关掉浏览器，千万不要因为本人的愚见，让你对大象口诛笔伐，进行人身攻击。
    HQL和QBC都是查询检索的方式，最开始，我一直使用的都是HQL，因为以前一直用的都是SQL，觉得这东西和SQL差不多，上手很快。后来又用QBC，因为QBC是基于接口和类的对象化查询，使代码变得很清晰，很整洁。
    下面是查询用户表中，id为2，年龄等于21，并且名字以J开头的两种查询语句，它们的结果都是一样，只是不同的表现方式。
    HQL:

    Query query = session
            .createQuery("from User u where u.id = 2 and u.age = 21 and u.name like 'J%'");
    List list = query.list();

    QBC：

    Criteria criteria  =  session.createCriteria(User. class );
    List list = criteria.add(Expression.eq("id", 2)).add(
            Expression.eq("age", 21)).add(Expression.like("name", "J%"))
            .list();

    如果查询再复杂一点，需要关联多张表，那上面这个HQL语句就会显得很复杂，比较难以阅读。对于QBC来说，需要再加一个createCriteria()，返回一个criteria新实例，比如说，用户表与帐号表关联，需要根据帐号表中的帐号，开户时间，金额等信息进行查询，可以写成下面的形式：

List list  =  criteria.add(Expression.eq( " id " ,  2 )).add(
                Expression.eq( " age " ,  21 )).add(Expression.like( " name " ,  " J% " ))
                .createCriteria( " account " , " a " ).add(
                        Expression.eq( " a.account_id " ,  112546 )).add(
                        Expression.eq( " a.start_date " ,  " 2008-8-30 " )).add(
                        Expression.eq( " a.money_sum " ,  1000 )).list();

    account是用户表中建的与帐号表的关联对象属性，a是别名。我为了便于说明，用的都是固定值，并且条件判断也都是eq（等于），其实在实际开发中，这是不可能的，这些值全都会被变量所代替。add方法也不用写在一起，可以分开来，特别是在查询中，需要对传入的参数进行检验，这时就需要一个条件一个条件的往上加。
    这样看来，好像QBC比HQL要好一些，大象是这么认为的：HQL简单、灵活，QBC整洁、方便，不能说谁好谁不好，否则大名鼎鼎的Hibernate为什么要支持这两种检索方式呢？
    根据本人做开发的情况来看，在需要多表关联查询的时候，如果POJO类之间建立一对多或多对多这样的关联关系，效率是很低下的，就算你设置了延迟检索，也会感觉很慢。而且在实际开发中，我还发现，在数据库中建立外键是一件非常吃力不讨好的事情，因为很多时候出错都是跟外键有关系，主要体现在修改和删除。而POJO之间建立对象关系，则会增加编码的复杂程度，提高出错机率，另外还会增加用户等待的时间。这是大象以前开发时所经历过的，所以后来的项目中，对于数据库中的每个表，只给一个流水号主键，不在建立其它的外键关系，而在POJO中，只设定最原始的属性与表中的字段对应，对于需要做多表查询的情况，建立视图，把需要查询的字段属性与要在列表中显示的字段属性都放在视图POJO中，这样，不管是HQL还是QBC，一个类就可以解决问题，而且对视图查询可比使用表之间的关联关系查询要快很多。
    在项目中，到底采取哪种检索方式，关键还得看项目负责人。比如大象现在做的这个项目就规定了，必须使用QBC，而且除报表外，不准使用视图。呵呵，这样的情况，只能在POJO之间建立关联关系了，不过能少建，我们还是会尽量的减少类之间的关联，好在现在开发用的JDK是5.0的，因此我们可以使用注解的方式定义一些临时对象属性，这样也省掉了以前必须得写的hbm.xml文件，有时也采用仿视图的方式用JavaBean来封装一些对象和属性。
    大家看到这里，有什么想法呢？欢迎大家提出自己宝贵的意见，我们一起来学习和研究，共同分享成功的经验。
    本文为菠萝大象原创，如要转载请注明出处。