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

bingle

感谢大家的意见，这样做确实维护起来还比较方便，但是正如许多人所说的，性能问题，比如大批量几百条数据插入，没法用预处理，导致来回访问数据好多次。

我是在insert语句中，第个传入的值都转换过数据类型的
如insert into tableName(field1,field2,field3...) values(cast("" as 数据类型),....)这样来做的－－－其中要对varchar().char()进行判断，因为他们有长度

取得数据类型：
select   C.name   as   ColName,O.Name   as   TableName,S.name   as   type,S.Length as length  from   dbo.syscolumns   C    
  Inner   Join   dbo.systypes   s   On   C.xtype=s.xtype  
  inner   Join   dbo.sysobjects   O   On   O.id=C.id  
  where   O.name='表名'   and   C.name='字段名' 

对于insert 语句中的field1,field2,field3可以通过建表的顺利来做（这样每个表操作时都是一样的）
取得表的列名顺序(但要除去自动增长列)：
select name from syscolumns where id in(select id from sysobjects
where name='表名') order by offset desc

除去自动增长列:
  select  name  from   syscolumns   where   id=object_id(N'v)   and   status=128  

在添加，删除列，修改列时，用的是alter table 操作.....

其实就是把rs结果转为map形式吧

不过我封装的是 key Object

前台用标签页可以遍历map输出

我以前维护过一个工作流的系统.
可以自动生成表,列,页面,script验证,
我认为非常的难用且难以维护

大哥，能不能说一说你的那个系统地实现思路。

楼主公司的框架不错啊。
这正好是 apache ofbiz 的思想，用Map思想来映射，我们2003年用过2年，很不错的一个框架。

楼主提出的两个缺点，Ofbiz已经考虑到了。
1.缓存问题，关键是每个Map没有一个类型标识，因此，你的DAO基类必须有一个 entityName 的属性，来区别这个实体和那个实体；
另外增加一个 Pk 属性，保存主键名，可以由底层查出sql结构后自动设置。
有了 entityName，和Pk ， 这样就和hibernate 类似了，实现缓存功能不在话下。

2. 特殊sql不用怕，可以改为配置型sql，在xml文件中配置。 如果你真的是跨数据库的产品，那么每个DBMS 提供一套 sql xml配置；移植到下一个DBMS 专门花几天来修改，调试就可以。相当于 Oracle版 ，DB2 版。

我觉得不如就有hashMap，就行！

这么搞就回到面向过程编程的老路上了

这么一折腾很多编译期就能发现的错误就被延迟到运行时了，不是跟写脚本差不多，不如直接用脚本语言去写，既快捷又方便，何必大费周折