只需要一个DAO，是个好主意吗？

原来我不用框架,只用JDBC的时候就用的这种方式,不过比较笨的
大概方法是 自己写了个DAO接口和实现,方法里有个String的参数,只要在参数里填写where等一些要变化的东西,在实现里进行拼装,这样每个DAO一般只要add,edit,del,list四个方法就够用了,getOne可以通过list.get(1)来实现

DAO层属于技术上的分层,主要用于DB操作与Service的解耦,如果有好的架构在这一块处理的话(比方JPA,Hibernate之类),DAO层基本上就失去存在的意义.但如果,你的业务足够的复杂,无法通过模块化变成简单业务,就算使用JPA之类的O/R Mapping产品还是要写QL(Query Language),那么DAO还是有存在的必要.
如果QL或SQL放在XML中,使得大量XML文件的出现,这里会涉及到2种不同的看法,一种认为这是类似于O/R Mapping的配置文件,属Model层面的东西,一种可以认为是类似于DAO层的Java对象(用XML替换了原有Java DAO的作用),属DAO层面的东西.我个人倾向于把它当作第一种看待.

只有一个DAO和去掉了DAO层基本等价,因为一个对象占住的一个分层是无实际含义的.这种设计方案在很多场合(比方50人以下的团队或是一万Man/Day以下)是很不错的.
其实还有一个好的判断标准来绝定你的DAO层有没有必要存在,稍列几条:
1) 你觉得代码生成工具对你们有好的帮助
2) 你们的DAO层,基本上都是一两行代码的小方法,或者去掉Model转Model,catch/throw异常后剩了一两行代码的小方法
3) 你们的DAO层,里面的方法名分类后,可以变成几个或十几个.(比方,所有DAO的方法就是这么些:search,get,add,update,delete,merge)

我觉得楼主没有认清什么是DAO
DAO即为数据访问对象，是一种设计模式，把访问数据库的操作封装成类的方式。
几乎所以的持久层框架都封装了它，可能具体的实现方式不同。
持久层框架提供了更高的一个层次的访问方式。

dao多少看个人喜好吧，不过建议泛型基本的CRUD。
现在喜欢用HibernateTemplate很好很强大。
咋没人说findByExample呢，很好用的。

我手上有个以前的项目就是用properties文件存SQL
然后搞很少的几个DAO来查数据库
这个项目现在是我的噩梦
应为那么多SQL语句，我每次要改的时候都要Ctrl+F去查半天

.....DAO模式是不是太古老了?以致于现在很多人都不清楚这个模式的具体含义.......
楼主.DAO模式还肩负着类型安全的重任,这个重任还能充分利用IDE的类型检查在开发阶段就避免类型安全错误.在你这里,这个模式不是进步,而是退化了.....

精辟

  我在新的框架里已经用了，不过得看我们技术总监怎么评价了，个人感觉这种方式挺好的，最大限度的做到了复用。

这几天在做数据统计的时候也　在考虑这东西，没想出一个好的解决方案。SQL的变化太多了，而且很多时候所涉及的业务查询千奇百怪的。很难去实际抽象出一种类型或是几种具体的方法出来。

我觉得一个BaseDAO然后继承，这样更好