我们项目用了这样一个DAO，大家分析一下。。。

这个DAO继承一个HashMap，用DAO的setField(name,value)设值，name是字段名称，value是String，字段值，其实setField就是用put往map里存。然后给DAO设置表名等其他属性，用create插入数据库，create实际上是先访问一次数据库，然后让数据库返回0长度的结果集，然后用resultset的Metadata对应着keySet里的值（字段名称）查询每个字段在数据库里的类型，这样就能判断拼接sql的时候是 a=‘123’还是a=123了最后把每个字段和值拼成sql插入。

感觉优点：
在数据库增加字段的时候很容易，只用修改库和页面，中间业务层什么都不用动就可以了

缺点：
1、在数据操作上扩展任何功能，比如数据缓存，都很困难
2、其实查询语句还是dao.find(sql)这样拼sql查找，导致某些人写了特殊的sql移植库时候无法使用

还有个好处就是根本不用考虑字段类型，任何都当String处理就可以了

当初是想做成一个通用的dao吧,而且还设想改数据库可以不改代码.不过...

你们能不能做到改数据库不用重新改代码,只要改改配置连界面都能自动调整的?
换句话说,如果你们的程序不能做到全部都用这种map就没意义.

丢失了强数据类型的优势,我没觉得有什么好的.

确实是改数据库不用改代码,配置都不用改,只需要在页面上增加需要的输入匡,输入匡名字与数据库字段名字一样,自动通过MAP影射过去了

我觉得蛮好，Delphi做在ＣＳ方面讲，数据库大家都认为做得不错吧，它就是这种方式去做的

这样的设计应该是让DAO变得线程不安全的，或者就是每次数据库操作都需要新获得一个DAO的实例才行。

不喜欢 KEY -value这种设计
脚像踩着泥地一样
找个字母错都要找N年.
说不定这个字母是从哪里传进来的呢.
有些魔术变量带着呼啸,
穿越了N层之后.....我头都大了
不得已bug单步跟啊跟的.....
找到问题又不能改架构
只能打补丁........

PS:有时多也是少.

ＥＸＴ的有关数据库方面的封装，也是用KEY -value这种设计，它将ＪＳＯＮ或ＸＭＬ或ＡＲＲＡＹ都转成了KEY -value

不错不错.这样不是挺好么?
所有的设计都要从需求来.你们的需求有这样的要求,那就是好的设计.