DetachedCriteria与Criteria的用方有哪些不同

这期内容当中小编将会给大家带来有关DetachedCriteria与Criteria的用方有哪些不同，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

在常规的Web编程中，有大量的动态条件查询，即用户在网页上面自由选择某些条件，程序根据用户的选择条件，动态生成SQL语句，进行查询。

比如，我记得在Facebook中可以选择高级查询条件，这个就是个动态的查询了塞，我们无法预知使用多少个查询，直接书写死了在我们的Dao层显然是不服和我们的意思的塞

针对这种需求，对于分层应用程序来说，Web层需要传递一个查询的条件列表给业务层对象，业务层对象获得这个条件列表之后，然后依次取出条件，构造查询语句。这里的一个难点是条件列表用什么来构造？传统上使用Map，但是这种方式缺陷很大，Map可以传递的信息非常有限，只能传递name和value，无法传递究竟要做怎样的条件运算，究竟是大于，小于，like，还是其它的什么，业务层对象必须确切掌握每条entry的隐含条件。因此一旦隐含条件改变，业务层对象的查询构造算法必须相应修改，但是这种查询条件的改变是隐式约定的，而不是程序代码约束的，因此非常容易出错。

DetachedCriteria可以解决这个问题，即在web层，程序员使用DetachedCriteria来构造查询条件，然后将这个 DetachedCriteria作为方法调用参数传递给业务层对象。而业务层对象获得DetachedCriteria之后，可以在session范围内直接构造Criteria，进行查询。就此，查询语句的构造完全被搬离到web层实现，而业务层则只负责完成持久化和查询的封装即可，与查询条件构造完全解耦，非常完美！

Criteria 和 DetachedCriteria 的主要区别

在于创建的形式不一样， Criteria 是在线的，所以它是由 Hibernate Session 进行创建的,而 DetachedCriteria 是离线的，创建时无需Session .

DetachedCriteria的创建

DetachedCriteria 提供了 2 个静态方法 ，进行DetachedCriteria 实例的创建。
forClass(Class)
forEntityName(Name)

Spring 的框架提供了对于离线查询的支持，非常的简单的使用那些方法

Spring 的框架提供了getHibernateTemplate().findByCriteria(detachedCriteria) 方法可以很方便地根据DetachedCriteria 来返回查询结果。Criteria的子类就是 DetachedCriteria 我们可以简单的使用就好了。

使用到了这些我们就不得不说 Restrictions

是产生查询条件的工具类。Restrictions表达式如下
HQL运算符 QBC运算符 含义
= Restrictions.eq() 等于equal
<> Restrictions.ne() 不等于 not equal

 Restrictions.gt() 大于greater than = Restrictions.ge() 大于等于 greater than or equal < Restrictions.lt() 小于less than <= Restrictions.le() 小 于 等 于 less than or equal is null Restrictions.isnull() 等于空值 is not null Restrictions.isNotNull() 非空值 like Restrictions.like() 字符串模式匹配 and Restrictions.and() 逻辑与 and Restrictions.conjunction() 逻辑与 or Restrictions.or() 逻辑或 or Restrictions.disjunction() 逻辑或 not Restrictions.not() 逻辑非 in(列表) Restrictions.in() 等于列表中的某一个值 not in(列表) Restrictions.not(Restrictions.in()) 不等于列表中任意一个值 between x and y Restrictions.between() 闭区间 xy中的任意值 not between x and y Restrictions.not(Restrictions..between()) 小于值X 或者大于值y