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

还不如 直接从页面的request以及该页面相对应的HQL一起组装呢，大家就开发页面可以了，也不用Map了。

你用preparedStatement也一样要区分数据类型，否则你怎么知道调用setString还是setInt
别人说的问题和你说的根本不是一回事。

跟我以前做过的类似，1层hashmap还无所谓，基本知道是和数据库对应，就怕多层架构统一使用hashMap.你不跟到里面根本不知道这个Map存的是什么

并且，因为你用HashMap就是为了去掉强类型，搞可伸缩，如果要想在较高层使用领域模型来规范，也是需要手动转换的，工作一点也没减少

想起有个问题是铁定解决不了的，因为这样做违背面向对象思想，这样一个map既可以put进user信息，又可以put进food信息，非常不利于扩招新操作，我还是倾向于将user表抽象成user类，然后user.create这样的操作。倘若将来希望所有用户信息插入到数据库的时候增加用户的年龄如果年龄小于20，按20算，则可以方便的生成一个user类的代理，在处理器中判断age是否小于20，如果用map则需要到处改代码。

还是放弃这种1杆子戳到底的做法吧，
起初的时候，页面上的字段和数据库的对应关系很简单，业务逻辑也很简单，这么做会觉得很方便。
但是危险的地方就是，当业务逻辑变得复杂，系统的层次变得多起来到时候，就抓狂吧。
这种设计对复杂业务逻辑的承受力极差。

首先我觉得这样做是放弃了orm思想。用一个hashmap确实在一定程度上对单表的crud操作简单了一些。但是正式由于放弃了
orm想，不能将关系数据库与oo联系起来，就无法利用oo的各个好处有点得不偿失。
其次这样做具有很大的限制性无法针对cache等方面进行操作。

只是你不了解preparedStatement，LZ的这个需求我老早用preparedStatement实现过了。
它只需要检查java本身类型就可以了，java类型判断用反射就行了，根本不用去获取数据表元数据。
比如传入参数为String 型，即使数据库中为INTEGER，调setString()可以插入,或者传入参数int,数据库中为varchar，调setInt()都是可以的,另外还有setObject()更为通用。格式不对不能转换的话会抛出SQLException（拼凑字符串同样会遇到格式不对的问题）。
而且拼凑sql字符串可以被sql注入攻击，很不安全，是很差的一种方式。

你那个DAO还要继承HashMap吗?我觉的是多余的，将这个东西作为参数传进来不是更方便吗！我去年在公司就碰到一个人就是这么干的！他要这么做，偶反对，讨厌这种非面向对象思考方式的设计。不过那人还举出例子说这么干已经多年了，还有一个超大的项目都是这么做的（好像是一个超大公司门户网站）。我晕倒了，为这事情还跟他炒起来了。除了思维方式和代码不容易维护之外，其他的问题应该都可以解决！至于性能，我那哥们的例子都证明是可以调优的！反正我是非常讨厌这种方式！

我曾经就用过很长一段时间的一个类似的框架，用起来确实很爽。不光是增减数据库字段的问题，做个在线定制啥的和hibernate比起来简直不可同日而语。对于大多数的MIS的程序员而言，用什么数据类型他们根本就没感觉，强类型检查对它们来说根本就是新的烦恼。

当然，在实现实际的业务逻辑的时候，我个人是喜欢用接口而不是用POJO类。持久化时用key-value，业务逻辑用接口，这不就两不耽误了吗？当然这个做起来是要比原始的key-value方式复杂一点点的。

不能说完全没作用，比如传统的ORMAP方式，一个user类对应一个user表，如果表增加字段，你还要改写user类才行，而用MAP，只不过是增加一组k-v而已