项目反思：DetachedCriteria需要吗？不需要吗？

Hibernate3中提供了DetachedCriteria的支持，使得开发的时候可以脱离Hibernate Session来构造查询，特别是可以将查询条件直接在Web层构造，但是在使用中一直存在着很大的争议：DetachedCriteria Bug明显，使用DetachedCriteria使得原本层次分明的结构又变得焦灼起来。而我在新的项目中使用真的是冒了比较大的风险，比起HQL、QBC来说，DC就显得非常的年轻，没有很多的成功范例让使用变得非常的危险。所以在这里说说自己的使用心得，DetachedCriteria是否有必要使用？
     代码部分参考Robbin的帖子：http://www.javaeye.com/post/86781。相对以往Hibernate的查询方法HQL、QBC，DetachedCriteria优势明显，它可以像HQL一样脱离Session构造查询条件，也可以像QBC一样采用完全面向对象的方式查询，这给Hibernate更多的自由发挥空间。

1.使用DC的时候，可以在Web层构造查询条件，而不用再在Dao层才去做烦乱的判断和Criteria.add()，让Dao更加的稳固的只尽其访问数据库的职责。
2.使用DC还能更多的节省代码，以往Dao的开发习惯都是将Dao与指定的Model进行绑定，而DC本身脱离了Dao，没有必要再对某个Dao单独去指定findAllByDc这样的方法，这样写一个公用的接口，每个需要使用DC查询的上层类直接访问这个公共借口就可以，使得相同的代码省了不少，减少Dao层代码的负担，不都说减少代码意味着减少测试和出现bug的几率么。
     “成也萧何、败也萧何”，为了能得到上面的这些好处，你就很可能和我一样遇到下面的麻烦：
1.查询代码又一次充斥在框架的各个层面上。可能有人会说使用DC的时候都是面向对象的构造查询条件，根本没有select from这样的字样，不算数据库操作，但是某天我一个昏头就将不能用DC实现的一个查询改成了HQL查询来做，也写了个类似的接口，可以接受各种构造好的HQL查询语句，然后再看看呢，猛然发现这不就是MVC没成型的时候到处都是SQL那种样子么？由于DC的自由度，项目中的DC马上就充斥了MVC各个层面，就好像我们刚使用Rails的时候（Rails更爽，页面上偷偷写写也还是满爽的，你没写过？Think about select_tag..
2.bug（应该叫待解决问题，小弟不才 ）。就单从这个项目里需要解决的bug就够我烦的，目前还有3个郁闷的bug悬在那里。
   A.left join查询，双向一对多，通过父方查询的时候，在子方添加查询条件就怎么都配写不好，反复去网上找答案，大家也反复各种组合，最终还是没能解决，其他left join都正常，就到ont-to-many在子方添加条件，left join 突然失灵，打印出的SQL居然不是left join查询，大家郁闷至极，为了赶项目，无奈又拿起HQL（这就是我为什么在Action里面构造HQL，那的确是相当的没辙）。
   B.order by问题，这个问题好像是伴随DC上镜率最高的问题，就在我参考的robbin的这个帖子里面大家也是尽其所能的想办法，但好像没有什么结果，所以我现在的查询就是这个样子：翻页查询的时候前10条记录和10－20条记录里面居然有重复……
   C.在分页查询的时候，如果查询结果集还关联set，那么就会有重复记录，尽管你可以通过LinkedSet过滤，但是分页的时候在结果集查出来之前没过滤，这结果显然是错误的，而Hibernate3中将returnMap()的过滤方法已经被移出……
    上面的问题很多是处在ont-to-many一方，可能有人会笑我的方法有问题，但是我用one-to-many是因为将many-to-many拆分处理的，我也没办法呀。
3.难于测试。这个问题我已经在版上提问过了：http://www.javaeye.com/topic/98026，如果想对Service层DC这种东西测试，就需要将它做成接口，然后Mock，这种大规模明显是为了测试而测试，时间上也不允许，老板也不同意，索性继续使用Spring-mock那种测试方案，不脱离Dao进行测试。

以上是我对DC在实际使用中的一点见解，其中有很多不成熟的地方，因为时间仓促，很多地方准备不足，而且现在还有一些问题无法解决，希望大家能给予自己的看法或者就我的问题提出解决方案 ：P。

    目前看，DC还是要用的，仅仅限制于Web层构造查询条件的时候使用，而其他情况的数据库操作仍然放回到Dao层去做，而对于DC中存在的Bug，不知道大家有啥想法，是等着Gavin哪天高兴了去解决呢还是我们自行了断，重构代码？