我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(1)

 

 

   【START 修改日志 当天 22：12 】：本文主要是针对基于Hibernate框架的项目开发中复杂查询的最佳实践。分析了前几个网友的意见，我想在几个基本方面hibernate QBC,QBE还是很方便的：

    1） 单表简单查询（基于字段的等值查询， 全部And运算）时，简单的汇总，如count等。

    2） 全动态查询条件， QBE很方便。

   【END 修改日志  当天 22：12 】

 

【START 修改日志 2008-9-19 21：20】：

   [quote="ziyuan"] ibatis完全符合lz的需求，，why not try it[/quote]

 

     同意你，我在公司项目中制定这个开发规范正符合 ibatis 的特点, 不过 Hibernate 对其也提供了完全的支持， 这两者在该功能上是一样的。

 

      因为 2006年项目启动时，已经确定使用 Hibernate 3， 而公司以前编程规范是使用 HQL, QBC 的 ， 正好那次在项目初期对Hibernate 这一使用规范逐渐纠  正过来。

      如果是新的项目， 我想 ibatis 也是可以考虑的方案。
【START 修改日志 2008-9-19 21：20】

 

   

 

    2006年公司电信项目启动时，项目组选择沿用使用已久 的Hibernate及开发规范做 ORM方案。 做为公司新的电信项目的架构师一员，根据一直以来的项目经验，在项目进行2月后，面对复杂查询业务陆续增多，原有以Hibernate HQL，QBC 为特点的开发规范有些无法很好满足需求。

  

    因此在分析复杂查询业务 及 Hibernate 的特性特点， 我为 Hibernate 开发时制定了一个规范：禁用 HQL,QBC,QBE编程, 有三个要点，对于非单表的简单查询：

 

    1）程序员不得在Java代码中直接使用HQL；

    2）不得进行HQL拼装；

    3） 不得在 hbm.xml 映射文件中使用named HQL query。

 

    该规范按重要程度 基于四个方面的考虑：业务复杂度，程序员开发效率，维护难度和执行性能。  规范要求在 Hibernate 的 hbm.xml  文件配置Named SQL Query 来进行这些功能的开发。

    项目中我们对其进行了适当的易用性改造，关于我们项目中Named SQL如何具体应用，见下一篇分享：我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(2)

 

1. HQL，QBC：

    今天写这个分享短文，源于前几天回覆网友icewubin 的帖子: “一个关于Hibernate的优化实例：从HQL到QBC，从QBC到QBE，再到‘增强的’QBE”，主要是Hibernate查询的几种使用方式：HQL，QBC，QBE。

    先说 QBC，QBE，例如：(Hibernate QBC 示例代码)

 

public List<Product> getProducts(Product product) { 
final Example exampleProduct = 
Example.create(product). 
enableLike(MatchMode.ANYWHERE). 
excludeZeroes(); 

return (List<Product>) getHibernateTemplate().execute( new HibernateCallback() { 
public Object doInHibernate(Session session) throws HibernateException { 
Criteria crit =session.createCriteria(Product.class). 
add(exampleProduct); 
return crit.list(); 
} 
} 
); 
}

 

或例如：(Hibernate QBC 构造查询条件示例代码)

Restrictions.ne(propertyName, propertyValue);
crit = Restrictions.gt(propertyName, propertyValue);
crit = Restrictions.lt(propertyName, propertyValue);

 
 

2 ORM框架下复杂查询的处理

 

    几年前，我使用另一个ORM框架Ofbiz, 它的QBC,QBE与Hibernate类似,而且条件构造的类库更为完善. 当时使用过JDBC编程的我也对这种纯Java的,优雅的查询编程吸引,折服(当然这种思想确实是大牛们的伟大创新), QBC,QBE对单表,简单查询条件,两表关联查询支持很好.

 

    然而当项目设计完毕,进入开发阶段后,我们发现,这种查询开发模式遇到了瓶颈. 因为当时项目是财务系统,业务比较复杂, 多表关联查询,汇总查询,子查询等复杂查询陆续涌来. QBC,QBE的不足马上体现出现. 为此项目组对此类业务不得不用改用native sql来开发, 为与Ofbiz的ORM思想保持统一, 以配置sql为数据源的实体成为虚拟实体(Virtual Entity), 虚拟实体同样在映射文件中配置. 这个对Ofbiz的封装和改造，马上发挥用途，项目顺利，流畅的推进了。

 

3. 我们的项目规范：禁用 HQL,QBC,QBE编程

 

    回到我们的2006年启动的电信项目，使用的是Hibernate，它增加了HQL，以OO的方式写查询语句，也是牛人Gavin King的力作。但与Ofbiz类似，它对多表关联查询,汇总查询,子查询，三者混合查询的支持依然不足。作为新任架构师经过对公司之前架构规范分析，及一番思考，决定使用Hibernate时的一个规范：禁用 HQL,QBC,QBE编程。

 

    在项目开发规范中，我对这个规范进行了要点分析和总结。

    HQL，QBC开发的缺点：
    1） Java代码和查询语言混合开发，没有分离，易读性，维护性差；
    2） HQL编写和调试困难，对于较为复杂的查询，通常需要转化为SQL进行调试，调试完毕又要转为HQL，转换过程需要对HQL有较好的理解，但容易出错，开发时间长；
    3） QBC 编码量多，开发慢，易读性，维护性差；
    4） HQL，QBC功能有限，前面提到的多表关联查询,汇总查询,子查询，三者混合查询支持不佳或无法支持。相信朋友们都遇到过类似的需求。

    5） 还有一个考虑就是性能问题，有的HQL被Hibernate内部组装为SQL后，可能存在性能隐患，如果修改的话比较麻烦。

 

4.  复杂查询的解决方案

   解决方案仍然是，在hbm.xml 文件中配置named sql query。Ibatis 也有类似功能。

 

例子1：查询指定模块的所有下级模块， Hibernate 能将查询结果自动和 ModuleVO 映射起来

 

<!-- 查询指定模块的所有下级模块 -->
	<sql-query name="system.module.queryAllSubModules">
			select  module.MODULE_CODE as MODULECODE,
                       module.MODULE_NAME as MODULENAME,
                       module.MODULE_TYPE as MODULETYPE,
                       module.PARENT_CODE as PARENTCODE,
                       module.MODULE_DESC as MODULEDESC,
                       module.MODULE_URI  as MODULEURI,
                       module.MODULE_VIEW as MODULEVIEW
			from 
			(
			select t.child_code, t.offset from sys_module_rela t
			where t.ancestor_code = :parentCode
			) m1 join sys_module module
			on m1.child_code = module.module_code
			order by parent_code, module_order
	</sql-query>

 

 

例子2：以判断操作员是否对某个URI有访问权限为例， 返回值 val 大于0时表示有权限：

<sql-query name="system.perm.hasURIPermisson">
    <return-scalar column="val" type="java.lang.Integer"/>
   select count(1) val from sys_module module ,
   (   select distinct p.module_code from sys_oper_perm op , sys_perm p
    where   op.oper_id = :oprcode and op.perm_code = p.perm_code )  op
   where
   module.module_code = op.module_code
   and  module.module_uri = :currentURI
</sql-query>

 

我们项目中的Java代码的调用就更为简单了：

/**
  * 检查指定工号对 web请求 uri是否有权限。
  * @param oprcode
  * @param currentURI
  * @return
  * @throws Exception
  */
 public boolean doCheckURIPermission(String oprcode, String currentURI) throws Exception {
  PermDAO dao = (PermDAO) DAOFactory.build(PermDAO.class,user);
  
  Param param = new Param();
  param.getQueryConditions().put("oprcode", oprcode);  //设置固定参数 :oprcode

  param.getQueryConditions().put("currentURI", currentURI); //设置固定参数 :currentURI

  Integer count = (Integer)dao.queryUniqueByNamedSqlQuery("system.perm.hasURIPermisson", param);
  return count.intValue() > 0;
 }

 

而如果使用HQL，估计很难实现；

使用QBC查询，至少需要2-3步，代码较多，并且可能或查出冗余数据， 影响应用性能。

 

named sql 的优点和上面HQL，QBC的缺点正好相反：

    1） Java 代码和查询语句分离，易读性好，维护性好；
    2） 使用原生 SQL 开发，调试简便。如果是oracle，在pl/sql中进行调试，修改快捷而高效；
    3） 原生 SQL功能自然不必说，它是最全的。复杂的业务如果它都支持不了，那就得歇菜了。
    4） 充分发挥 DBMS 本身特定sql 语法的特性。

 

 5. 跨数据库问题

    在和网友icewubin 的讨论中，有一个问题值得说一说：跨数据库问题。他的意思是使用HQL，QBC可以保持数据库通用，这是他们的项目需求。实际上，我们当初的项目也是要求跨数据库的。解决方法是，针对Oracle，DB2，Informix等客户可能用到的db专门做sql调整， 也就是有两个DB的 sql 实现，（当时为新客户调整到DB2 sql，也就花了一周时间）。
    这个方案与Oracle BPEL等产品一样，例如：改产品出厂时，有针对不同数据库的DDL脚本文件，一个道理。

 

6.  Named SQL在我们项目中的具体应用。

 

    我们对其进行了适当的易用性改造，关于我们项目中Named SQL如何具体应用，要工作了，呵呵。下一篇分享文章，再聊. 我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(2)

评论

17 楼 melode11 2008-09-19  

用named sql query还用什么hibernate...

另外，hibernate的文档中提到了，hibernate是对并发处理非常好的框架，在[高并发]和[合理使用]的情况下，性能可以达到jdbc的水平。

16 楼 nihongye 2008-09-19  

如果开发人员多，查询要求复杂，开发人员对数据库优化的知识参差不齐，从加快开发上看，楼主提供的主意不失为一个好主意。

15 楼 goodfifa07 2008-09-19  

HQL麻烦，那就Criteria，完全基于对象。

14 楼 nextw3 2008-09-19  

我是这样看的，如果开发的系统数据库完全是自己来设计的，并且设计合理，用hibernate合适，因为这种情况查询不复杂。而一些所谓的数据整合（从客户原数据库中整合数据），这种情况hibernate不合适的，

13 楼 nextw3 2008-09-19  

复杂的查询用hibernate确实不合适，性能一定会成为问题，我也很奇怪这种情况为什么用hibernate那？是不是只是为了“部分QBC的单表简单查询功能”？很难理解

12 楼 fuwang 2008-09-19  

我要抛弃hibernate，决定用ibatis之类的东西了。
不是hibernate不好，而是hibernate太深了，我玩不转，我觉得我再用几年也精通不了。
要做一个让人放心的业务系统，需要对hibernate非常熟悉，把hibernate用好才能做出来。
看看周边的情况，基本都是菜鸟在用 hibernate，做了几年的菜鸟在教新手如何用hibernate。
老板、售前、实施、项目经理都在叫:不就是增删改查吗？要有多简单就有多简单!

11 楼 stephen_chenxifei 2008-09-19  

其实在实际系统中可以灵活应用的，对于简单业务对象可以是hibernate，效率是很高的，对于多表操作比较复杂的情况，用native sql其实也是很不错的，容易维护和处理。两个平衡下，看你怎么来用了。

10 楼 badqiu 2008-09-16  

引用

    HQL，QBC开发的缺点：
    1） Java代码和查询语言混合开发，没有分离，易读性，维护性差；
    2） HQL编写和调试困难，对于较为复杂的查询，通常需要转化为SQL进行调试，调试完毕又要转为HQL，转换过程需要对HQL有较好的理解，但容易出错，开发时间长；
    3） QBC 编码量多，开发慢，易读性，维护性差；
    4） HQL，QBC功能有限，前面提到的多表关联查询,汇总查询,子查询，三者混合查询支持不佳或无法支持。相信朋友们都遇到过类似的需求。

    5） 还有一个考虑就是性能问题，有的HQL被Hibernate内部组装为SQL后，可能存在性能隐患，如果修改的话比较麻烦。

1)不知道在配置文件与java代码切换来切换去很麻烦么？你完全可以定个规范如将sql全部定为常量写在dao的前部，一目了然
2)这部分可以推dao单元测试，避免测一条sql需启动服务器,效果不错的。还有一个Hibernate Tool的工具，有一个类似测sql的UI控制台
3)QBC我也不用。这东西增加很多学习成本。看惯了sql,不如sql/hql直观.
4)hql一般需要使用的都支持，没必要为了1%的不支持特性放弃hql提供的那么多便利。
5)欲加之罪，懒的反驳

9 楼 raymond2006k 2008-09-16  

魔力猫咪 写道

用Hibernate用到这个份上还不如不用。首先是你们对性能到底要求多高？Hibernate比纯JDBC慢是肯定的。CACHE优化提升的具体效果要看具体业务情况。也许很好，也许没什么提升。所以如果你们对速度要求极高，那么还是不要用这个了，直接JDBC吧。嫌纯JDBC还不够快的话就只有自己写应用层缓存控制了。
其次是所谓的查询复杂到底是怎么回事情？是否有设计不合理的地方？很多面向数据库设计的系统用Hibernate都非常痛苦。因为他们很多都只是把Hibernate当作简化的SQL用了。Hibernate的良好实践前提是面向对象设计。
所以我的看法是，这些项目要么技术选型不正确，要么设计有问题。

Hibernate 的核心功能是ORM，即JavaBean 和 JDBC数据集合通过HBM.xml文件自动映射，实现面向对象的数据操作，这个没错。像关联映射，关联抓取等。
不过HQL，QBC都只是对这一核心的扩展，更体现了 OO 的风格， 即实现完全通过Java代码来操作数据的目标。

至于项目实践，需要以真实的开发效率，易用性等来衡量。我主要只用ORM的映射这一核心功能，和部分QBC的单表简单查询功能， 及Hibernate提供的数据源管理等。 而不会为了用面向对象设计而不顾效率，易用性， 即不会“为面向对象而面向对象”。

使用named sql能提高执行效率，但不是定这个规范的原始动力。

8 楼 mazzystar 2008-09-16  

不考虑跨数据库，为什么要用hibernate？
如果只用native sql ,为什么不用ibatis?

7 楼 魔力猫咪 2008-09-16  

用Hibernate用到这个份上还不如不用。首先是你们对性能到底要求多高？Hibernate比纯JDBC慢是肯定的。CACHE优化提升的具体效果要看具体业务情况。也许很好，也许没什么提升。所以如果你们对速度要求极高，那么还是不要用这个了，直接JDBC吧。嫌纯JDBC还不够快的话就只有自己写应用层缓存控制了。
其次是所谓的查询复杂到底是怎么回事情？是否有设计不合理的地方？很多面向数据库设计的系统用Hibernate都非常痛苦。因为他们很多都只是把Hibernate当作简化的SQL用了。Hibernate的良好实践前提是面向对象设计。
所以我的看法是，这些项目要么技术选型不正确，要么设计有问题。

6 楼 farryu 2008-09-16  

帮助
退出
设置
我的圈子
我的博客
收件箱 (0)
欢迎 farryu !

论坛首页 → Java版 → Hibernate → 我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(1)
全部 Hibernate Spring Struts Webwork iBATIS 企业应用 设计模式 DAO 领域模型 OO Tomcat SOA JBoss J2ME

浏览 92 次
主题：我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(1)精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
raymond2006k
等级: 初级会员

性别:
文章: 10
积分: 70
来自: 广州

时间：5 小时前 关键字: hibernate hql qbc引用 收藏


    做为公司电信项目的架构师，根据一直以来的项目经验，我在公司电信项目架构中涉及Hibernate开发时制定了一个规范：禁用 HQL,QBC,QBE编程, 有三个要点，对于非单表的简单查询：
    1）程序员不得在Java代码中直接使用HQL；
    2）不得进行HQL拼装；
    3） 不得在 hbm.xml 映射文件中使用named HQL query。

    那使用什么呢?  Hibernate Named SQL Query。
    我们对其进行了适当的易用性改造，关于我们项目中Named SQL如何具体应用，见下一篇分享：我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(2)

1. HQL，QBC：
    今天写这个分享短文，源于前几天回覆网友icewubin 的帖子: “一个关于Hibernate的优化实例：从HQL到QBC，从QBC到QBE，再到‘增强的’QBE”，主要是Hibernate查询的几种使用方式：HQL，QBC，QBE。
    先说 QBC，QBE，例如：(Hibernate QBC 示例代码)

Java代码
public List<Product> getProducts(Product product) {  
final Example exampleProduct =  
Example.create(product).  
enableLike(MatchMode.ANYWHERE).  
excludeZeroes();  
 
return (List<Product>) getHibernateTemplate().execute( new HibernateCallback() {  
public Object doInHibernate(Session session) throws HibernateException {  
Criteria crit =session.createCriteria(Product.class).  
add(exampleProduct);  
return crit.list();  
}  
}  
);  
} 

或例如：(Hibernate QBC 构造查询条件示例代码)
Java代码
Restrictions.ne(propertyName, propertyValue); 
crit = Restrictions.gt(propertyName, propertyValue); 
crit = Restrictions.lt(propertyName, propertyValue); 


2 ORM框架下复杂查询的处理

    几年前，我使用另一个ORM框架Ofbiz, 它的QBC,QBE与Hibernate类似,而且条件构造的类库更为完善. 当时使用过JDBC编程的我也对这种纯Java的,优雅的查询编程吸引,折服(当然这种思想确实是大牛们的伟大创新), QBC,QBE对单表,简单查询条件,两表关联查询支持很好.

    然而当项目设计完毕,进入开发阶段后,我们发现,这种查询开发模式遇到了瓶颈. 因为当时项目是财务系统,业务比较复杂, 多表关联查询,汇总查询,子查询等复杂查询陆续涌来. QBC,QBE的不足马上体现出现. 为此项目组对此类业务不得不用改用native sql来开发, 为与Ofbiz的ORM思想保持统一, 以配置sql为数据源的实体成为虚拟实体(Virtual Entity), 虚拟实体同样在映射文件中配置. 这个对Ofbiz的封装和改造，马上发挥用途，项目顺利，流畅的推进了。

3. 我们的项目规范：禁用 HQL,QBC,QBE编程

    回到我们的2006年启动的电信项目，使用的是Hibernate，它增加了HQL，以OO的方式写查询语句，也是牛人Gavin King的力作。但与Ofbiz类似，它对多表关联查询,汇总查询,子查询，三者混合查询的支持依然不足。作为新任架构师经过对公司之前架构规范分析，及一番思考，决定使用Hibernate时的一个规范：禁用 HQL,QBC,QBE编程。

    在项目开发规范中，我对这个规范进行了要点分析和总结。
    HQL，QBC开发的缺点：
    1） Java代码和查询语言混合开发，没有分离，易读性，维护性差；
    2） HQL编写和调试困难，对于较为复杂的查询，通常需要转化为SQL进行调试，调试完毕又要转为HQL，转换过程需要对HQL有较好的理解，但容易出错，开发时间长；
    3） QBC 编码量多，开发慢，易读性，维护性差；
    4） HQL，QBC功能有限，前面提到的多表关联查询,汇总查询,子查询，三者混合查询支持不佳或无法支持。相信朋友们都遇到过类似的需求。
    5） 还有一个考虑就是性能问题，有的HQL被Hibernate内部组装为SQL后，可能存在性能隐患，如果修改的话比较麻烦。

4.  复杂查询的解决方案
   解决方案仍然是，使用native sql。由于Hibernate named sql query本身对其已经支持的较好，为什么不用呢？ named sql 在hbm.xml 文件中配置，以判断操作员是否对某个URI有访问权限为例， 返回值 val 大于0时表示有权限：
Xml代码
<sql-query name="system.perm.hasURIPermisson"> 
    <return-scalar column="val" type="java.lang.Integer"/> 
   select count(1) val from sys_module module , 
   (   select distinct p.module_code from sys_oper_perm op , sys_perm p 
    where   op.oper_id =prcode and op.perm_code = p.perm_code )  op 
   where 
   module.module_code = op.module_code 
   and  module.module_uri = :currentURI 
</sql-query> 

我们项目中的Java代码的调用就更为简单了：
Java代码
/**
  * 检查指定工号对 web请求 uri是否有权限。
  * @param oprcode
  * @param currentURI
  * @return
  * @throws Exception
  */ 
public boolean doCheckURIPermission(String oprcode, String currentURI) throws Exception { 
  PermDAO dao = (PermDAO) DAOFactory.build(PermDAO.class,user); 
   
  Param param = new Param(); 
  param.getQueryConditions().put("oprcode", oprcode);  //设置固定参数prcode 
 
  param.getQueryConditions().put("currentURI", currentURI); //设置固定参数 :currentURI 
 
  Integer count = (Integer)dao.queryUniqueByNamedSqlQuery("system.perm.hasURIPermisson", param); 
  return count.intValue() > 0; 
} 

而如果使用HQL，估计很难实现；
使用QBC查询，至少需要2-3步，代码较多，并且可能或查出冗余数据， 影响应用性能。

named sql 的优点和上面HQL，QBC的缺点正好相反：
    1） Java 代码和查询语句分离，易读性好，维护性好；
    2） 使用原生 SQL 开发，调试简便。如果是oracle，在pl/sql中进行调试，修改快捷而高效；
    3） 原生 SQL功能自然不必说，它是最全的。复杂的业务如果它都支持不了，那就得歇菜了。
    4） 充分发挥 DBMS 本身特定sql 语法的特性。

5. 跨数据库问题
    在和网友icewubin 的讨论中，有一个问题值得说一说：跨数据库问题。他的意思是使用HQL，QBC可以保持数据库通用，这是他们的项目需求。实际上，我们当初的项目也是要求跨数据库的。解决方法是，针对Oracle，DB2，Informix等客户可能用到的db专门做sql调整， 也就是有两个DB的 sql 实现，（当时为新客户调整到DB2 sql，也就花了一周时间）。
    这个方案与Oracle BPEL等产品一样，例如：改产品出厂时，有针对不同数据库的DDL脚本文件，一个道理。

6.  Named SQL在我们项目中的具体应用。

    我们对其进行了适当的易用性改造，关于我们项目中Named SQL如何具体应用，要工作了，呵呵。下一篇分享文章，再聊. 我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(2)
声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
在繁琐中挣扎还是简化自主管理？
辉煌盛会-微软WinHec 2008 邀您共赴卓越！
IBM Rational软件开发高峰论坛9月揭幕
返回顶楼   
bluemare
等级: 初级会员

性别:
文章: 5
积分: 10
来自: 苏州

时间：3 小时前 引用 收藏
的确，写个复杂的sql可以，写个复杂的hql头大。
不过有的时候还是要看情况而定，简单表结构的可以直接hql等，对于结构复杂的就用sql-query。混合着来.
返回顶楼    0 0
upheart
等级: 初级会员

性别:
文章: 14
积分: 30
来自: 北京

时间：3 小时前 引用 收藏
很想知道，如果一个查询条件是动态的，比如根据用户输入的查询条件来构造，那这种方案怎么做？
返回顶楼    0 0
downpour
等级:

性别:
文章: 761
积分: 1638

时间：3 小时前 引用 收藏
既然如此，为什么还要Hibernate，JdbcTemplate直接解决你所有的问题。

所有的语句写在配置文件中，结果维护的时候，找一句SQL要代码配置联合起来看，非常麻烦。除了后期进行SQL调优时比较直观以外，没什么很大的好处。

代码中拼SQL有时候不可避免，如果觉得拼SQL都不能接收，干脆走Store procedure路线。
返回顶楼    0 0
miaomiao0307
等级: 初级会员

性别:
文章: 11
积分: 0
来自: 大连

时间：2 小时前 引用 收藏
有点像ibatis，我曾经做过一个项目，由于第一次使用，所以觉得hibernate很不方便，特别是hql，拥有自己的语法，不好维护，而且对数据操作的方法太多了，就一个分页，我们就做重了好几套
返回顶楼    0 0
raymond2006k
等级: 初级会员

性别:
文章: 10
积分: 70
来自: 广州

时间：44 分钟前 引用 收藏
upheart 写道
很想知道，如果一个查询条件是动态的，比如根据用户输入的查询条件来构造，那这种方案怎么做？



这就是Hibernate Named SQL 功能的轻微缺陷。
分两种情况：有限动态，任意动态。
前者是同一需求“不同逻辑情形的一个有限集合”，select 字句可以枚举。做法是：有几个，就设计几个named sql query。例如：按根据用户选择的查询模式，有按部门，按营销组，按个人三种查询。
后者是一个不确定的返回字段的不定集合，我在项目中的方案是对 Named SQL 功能进行了简单的封装，可以很好的支持 “查询条件是动态”。 下篇帖子中会简单说明解决方案。
返回顶楼    0 0

论坛首页 → Java版 → Hibernate

跳转论坛:
JavaEye推荐
快速回复 引用上一条消息 (Alt+S) 
首页
新闻
论坛
问答
知识库
博客
圈子
招聘 New
服务
搜索
Java
Ruby
AJAX
敏捷
图书
Oracle
普元
广告服务 JavaEye黑板报 网站地图 关于我们 联系我们 友情链接
© 2003-2008 iteye.com. All rights reserved. 上海炯耐计算机软件有限公司 [ 沪ICP备05023328号 ]

5 楼 raymond2006k 2008-09-16  

upheart 写道

很想知道，如果一个查询条件是动态的，比如根据用户输入的查询条件来构造，那这种方案怎么做？

这就是Hibernate Named SQL 功能的轻微缺陷。
分两种情况：有限动态，任意动态。
前者是同一需求“不同逻辑情形的一个有限集合”，select 字句可以枚举。做法是：有几个，就设计几个named sql query。例如：按根据用户选择的查询模式，有按部门，按营销组，按个人三种查询。
后者是一个不确定的返回字段的不定集合，我在项目中的方案是对 Named SQL 功能进行了简单的封装，可以很好的支持 “查询条件是动态”。 下篇帖子中会简单说明解决方案。

4 楼 miaomiao0307 2008-09-16  

有点像ibatis，我曾经做过一个项目，由于第一次使用，所以觉得hibernate很不方便，特别是hql，拥有自己的语法，不好维护，而且对数据操作的方法太多了，就一个分页，我们就做重了好几套

3 楼 downpour 2008-09-16  

既然如此，为什么还要Hibernate，JdbcTemplate直接解决你所有的问题。

所有的语句写在配置文件中，结果维护的时候，找一句SQL要代码配置联合起来看，非常麻烦。除了后期进行SQL调优时比较直观以外，没什么很大的好处。

代码中拼SQL有时候不可避免，如果觉得拼SQL都不能接收，干脆走Store procedure路线。

2 楼 upheart 2008-09-16  

很想知道，如果一个查询条件是动态的，比如根据用户输入的查询条件来构造，那这种方案怎么做？

1 楼 bluemare 2008-09-16  

的确，写个复杂的sql可以，写个复杂的hql头大。
不过有的时候还是要看情况而定，简单表结构的可以直接hql等，对于结构复杂的就用sql-query。混合着来.