模仿Warp Dynamic Finder的Hibernate Dynamic Dao

一个人说他的磁性螺丝刀很有用，可以将螺丝吸附在螺丝刀头上，会比一般的螺丝刀方便一些。

另一个人说螺丝刀不是盖房子的全部，盖房子时最卡时间的不是小小的螺丝刀，而是....

我不明白你的话是什么意思，这个东西本来就是个DEMO性质的，企业应用不只是DAO，一个DAO工具不可能解决的企业应用

中100%的问题，没有人有说这个DAO工具的出现可以将企业应用中最卡时间的问题解决，谢谢。

约定的确让很多事情变的简单，并且不用考虑太多东西 挺敏捷的

sorry，可能是我开始表意不是很清楚。

我觉得关于螺丝刀的使用场景应该是这样的。
盖房子的设计师给下面的施工人员提供了螺丝刀A，该螺丝刀非常的方便好用，修房子的过程中基本90%的螺丝都可以轻松搞定，不过需要一定的使用技巧。但是突然有一天，遇到了一种比较特别的螺丝，该螺丝刀不提供支持，施工人员找设计师，请求解决方法。设计师告诉他们，不好意思，对于特殊螺丝的处理，该螺丝刀并不能通过添加新的功能来支持，让我考虑考虑，再给你们找一套新的螺丝刀用来对该特殊螺丝的支持，并且在此之前，对于新的螺丝刀，需要对你们还进行一些使用培训。
my god。如果你是施工人员，这个时候难道不会抓狂？

我是觉得这样的DAO框架在本身简单易行的同时，需要提供足够的可扩展性，对于一些比较复杂的特殊需求，能够方便的扩展。只有这样在开发的后期才不会因为一些比较特殊的问题而搞的头破血流。

S2Dao提供的最基础的功能和仁兄的基本一样，S2Dao还提供一些更加强大的功能，不过到了后期，为了一些特殊需求，我要频繁的进入S2Dao的源代码进行修改。这种频繁修改开源项目代码的事虽然干起来过瘾，但并不是一个项目所乐意见到的，技术风险太大了。

DAO层本身是不能解决100%的企业问题，但是它是一个层，和数据库的交互都依赖于它。我不喜欢在使用某个dao工具的同时还去使用另外一种dao工具。这些是高手做的事，并不适合一些普通项目中的一些普通员工。如果一个项目的dao层中ibatis，hibernate，jdbc同时存在，很可怕，很可怕。


关于这种annotation dao的设计，仁兄可以参考下S2dao的。我把我所知道的列下来，如果能对你的设计有一点点的帮助。

1：关于很长的sql。这样的sql如果用annotation直接放在代码里面，简单的dao的interface会看起来非常的臃肿。
可以考虑添加函数级别的annotation  @sqlfile. 该annotation让该函数和某个特定的sql文件绑定起来。
2：结构类型参数的支持。 寻址方式采用ognl。

class Student
   public String name;
   public String address;

}

@SqlFile
List<Student> getStudent(Student student)

StudentDao_getStudent.sql

select * from student where name=/*student.name*/ and address =/*student.address*/

不过约定多了magic的东西也多了，对于开发成员能力普遍比较高的小团体，magic的东西不是问题。但是对于一些开发人员参差不齐，规模大但技术难度并不高，基础编码人员有一定流动性的项目。约定太多会给项目带来进入难度加大，新人的培训代价过高的缺点。 之前robin关于ror为什么不能大规模进入企业的评价深入我心。我想这种约定大于配置，魔法元素过多的框架设计思想，最好用处的确是用来体现绝顶高手的强，让人们看到企业开发如果做到一定的极致能达到如斯效率。并不一定能适合其它的大范围开发。

谢谢你的建议，一个框架没有试图做所有事，就是提供可扩展的空间，一种特殊的螺丝，你的螺丝刀搞不定，那拿来能搞定的螺丝刀搞好了，so easy，复杂的查询逻辑，你可以自己实现，继承HibernateDaoSupport或者随便怎么样，大部分简单的用DynamicDao，它只是对hibernate那些API进行了封装，这样不会有任何问题的。

另外，复杂的HQL放在代码里就是很臃肿，hibernate提供了分离HQL到外部的功能，named query，在DynamicDao只需要这样

     @Query(name = "queryByXXXX")//
     public Student queryByXXXX(.....)
     //这里封装了，session.getNamedQuery(String queryName),会将该名称对应的hql从配置文件里读出来创建query对象

一种特殊的螺丝，你的螺丝刀搞不定，那拿来能搞定的螺丝刀搞好了，so easy
我想这个点是我们俩意见不一样的地方。
我是觉得螺丝刀应该提供可扩展的接口，好比那种多功能的螺丝刀，换个螺丝头都可以搞其它的螺丝。如果因为特殊螺丝就需要使用特定的螺丝刀，代价大了点。

hibernate 最开始对于批量的删除没有好的解决方法，还是要依赖于jdbc，这样的东西偶实在不喜欢。不知道现在的hibernate发展到什么地步，是否可以不另外使用jdbc没。

代价为什么大？大在哪了？我实在不明白。。。

另外，hibernate2年前就提供了批量删除和更新的API

详见query.executeUpdate();

再次更新，加入动态条件插入，支持like，详见一楼，呵呵。

要说DAO,grails的实现比warp简单多了

这位仁兄说的很好！不过偶还是很喜欢去学习魔法的。实际项目中应用看来要找到志同道合者一起了， 庸者勿扰。