给大家讲一个关于map和bean的故事（在SpringJdbc玩map被玩死）

下面要给大家讲一个关于map和bean的故事。。。

（在spring jdbc玩map被玩死）

bean：pojo类，我习惯叫bean，有时候也叫他entity，实体类。

不要在springjdbc里玩map，这不是演习！！！
------------------------------------------------

前戏：

还记得很久以前，我在上学的时候，老师教我们什么叫数据库，什么叫SQL，怎么使用JDBC去连接数据库，然后写一坨代码：

....
02.Connection conn = null; 
03.PreparedStatement pstmt = null;
04.try {
05.conn = getConnection(); //1.获取JDBC连接 
06.String sql = "select * from tableName"; //2.声明SQL
07.pstmt = conn.prepareStatement(sql); //3.预编译SQL
08.ResultSet rs = pstmt.executeQuery(); //4.执行SQL
09.process(rs); //5.处理结果集
10.closeResultSet(rs); //5.释放结果集
11.closeStatement(pstmt); //6.释放Statement 
12.conn.commit(); //8.提交事务
13.} catch (Exception e) { 
14.//9.处理异常并回滚事务
15.conn.rollback();
16.throw e;
17.} finally {
18.//10.释放JDBC连接，防止JDBC连接不关闭造成的内存泄漏
19.closeConnection(conn);
20.}
21.....

之后，战战兢兢的去用eclipse启动服务，oh yes！

数据库里的数据神奇的出来了！！！

之后会了单表CRUD，我就敢自信满满的在简历上写着“精通jdbc”了。。。

。。。

ok，谁都有过青春，不是吗？

------------------------------------------------

时光荏苒，一晃就毕业了，进入到了工作岗位中，由于之前的JDBC连接数据库的方式实在是太繁琐了，并且很有可能一不小心漏掉了什么，就出现了bug。

并且使用JDBC后，我还得费劲巴拉的把resultSet里的东西给自己转成bean里，so？

我们用了hibernate。。。

当年斥叉风云SSH框架（struts/spring/hibernate），一时间，风起云涌，好像只要会SSH就可以找到好工作了，不会SSH就不敢跟别人打招呼。

然后hibernate并不是那么想象中的完美。

我总结出的hibernate的缺点/痛点有（也是某些公司的面试题）：

1.hibernate传说中的不用写sql，是很强大，配置好了之后，你就看你的控制台上输出的sql吧，如果你的项目不care性能。（哪个项目不care性能？除非是毕设~）

2.当年的那个OneToMany,ManyToOne,OneToOne的配置的确让我痛苦了一阵子，我承认我很low。。。

3.hibernate传说中的hql和方言，亲，无论你换成什么数据库，都不用修改我们的hql哟~只要换方言就可以啦，但是哪个项目会经常换数据库呢？并且hql不支持复杂的sql写法，我觉得挺鸡肋的功能。

4.我记忆犹新的一件事，当时数据查出来了之后，到页面上就报错，结果搜索了一下，发现是什么hibernate的session已经关闭了，需要借用spring的一个什么东西才能好。

5.hibernate传说中的二级缓存，玩不好能玩死你，并且现在谁还用spring/hibernate的缓存啊？现在都是分布式/大数据的时代，全是分布式redis，memcache的年代了。

6.各种各样的复杂概念，各种复杂配置，什么延迟加载啊，session的生命周期啊，哦，我的天。

7.学习成本高

经历了一些事情之后，开始学会慢慢的长大，有那么句话叫：“经历的多了，也就成熟了。”

后来和几个同事聊了很多关于hibernate的优缺点，发现hibernate的优点我们都用不上，用上的都是痛点，

于是痛定思痛，决定摒弃hibernate，寻找新的持久层框架。

------------------------------------------------

之后接触了spring jdbc，mybatis，spring data jpa等框架。

当时就想一直用一个持久层框架，配合各种自己写的半自动化代码生成工具以及baseDao，可以节省大量工作量，时间就是金钱，我的朋友。

这些框架各有千秋，选来选去，忽然间发现spring jdbc的namedParameterJdbcTemplate里无论是入参，还是返回值，都可以玩Map，我当时头脑一热，这下好啦：

1.首先spring jdbc是spring的亲儿子，应该不会出什么兼容性问题的幺蛾子。

2.Map非常灵活呀，想放什么就放什么，想拿什么就拿什么，都是Object嘛。

3.最重要的一点是，可以完全摒弃了bean，之前表一多，各种bean满天飞的时代一去不复返啦，现在只要Map，Map在手，天下我有。

经过短暂的头发发热之后，开始风风火火的封baseDao，写自动生成工具，然后风风火火的接项目（自己创业期间），开始干！

做了几个小项目，发现，恩~map还真真儿的不错呢，好方便呀，我封好的baseDao里基本上涵盖了所有dao里80%的代码，项目组里的小盆友们甚至不用写dao，但是痛点也来了，service层上耦合了大量dao的东西，非常乱，因为当时是小项目，痛点没有凸现出来，直到。。。。。。。

直到做了所谓的中型项目后，一旦人一多，表一多，逻辑一多，玩多模块多项目开发的时候，各种依赖的时候。。。

oh no。。。

------------------------------------------------

前戏结束，步入正题，下面列出map和bean的优缺点：

map的优点：

1.灵活，通用，相当于是一个大泛型，也可以转成bean。

2.大幅提高开发速度（开发层面）

3.数据库频繁变动的前提下，几乎很少的去修改代码。

4.节省了bean的维护工作，项目中几乎找不到bean了。

5.和spring一脉相承，不需要额外的配置来转化bean，以及额外的bug，（这里说的是spring jdbc）

map的缺点：

1.不直观，开发人员不清楚map里有什么字段，每个字段具体是什么数据类型，前提是知道表结构。

2.使用表单validation框架时，需要创建表单bean

3.每次取值的时候都要手写字段名称，有时需要强制类型转换，如果用bean就没有这个痛点了。

4.难维护

5.项目大了以后，玩分模块，玩微服务，痛点更明显

6.项目大了之后，在不同的地方调用db返回的数据，自己都不知道应该查哪个字段

7.一旦字段更改后，如果有地方想不到，那就会造成隐藏bug，如果用bean的话，直接eclipse就会报错，减少bug几率。

8.put/get数据的时候频率是很高的，Map的话，get还需要写字段，每次put和get的时候都要编写大量代码，以及类型转换。

9.数据库一变更之后，大面积的map.put/get 都不报错，自己也不知道该改哪里，不该改哪里。一启动服务后全是错，但是用bean，直接就会出红叉，知道该改哪里。

------------------------------------------------
bean的优点：

1.直观，开发人员清楚的知道bean里有什么字段,什么类型。
2.使用表单validation框架时，可以直接使用已生成的bean
3.新人上手快
4.易维护

bean的缺点：

1.多表联查的时候还需要自己创建bean（看你的sql复杂不复杂，也可以考虑建大bean来解决）
2.开发效率不是很高（在频繁修改数据库的情况下，会带来额外的代码修改工作量）。

------------------------------------------------

尾声：

之前在我用Map开始干的时候，也询问过一些朋友，大家总体的反应是小项目用map玩玩可以，但是大项目就要用bean。

现在想想。。。拉倒吧，小项目也别用map了，好习惯早养成。

我当时没在乎，我就是想试试到底有多痛。。。

结果真的很痛。。。

后来痛的要死的时候，发现其实spring jdbc是原生支持玩bean的，结果花了2天一股脑又封了一个基于bean的baseDao，现在项目里是既有bean，又有map。

慢慢来吧，少年。

好啦，这就是我要给你们讲的map和bean的故事。

------------------------------------------------