来自：码农翻身（）
1断电的威胁强大的Java帝国自成立一来，一直顺风顺水，可是外人不知道的是，帝国也有个致命的弱点，那就是害怕一种叫做“断电”的攻击。
每次攻击来临，帝国辛辛苦苦制造出Java对象都会瞬间死亡，变成孤魂野鬼，在电脑里四处游荡，最终悄无声息地消失在空气中。
这是没有办法的事情，帝国生存所依仗的Java对象都必须在内存中才能工作，而内存最怕“断电”！
这件事情变成了国王的一件心病，茶不思饭不想。
某日朝会，国王又把这个难题抛给了下面战战兢兢的各位大臣。
线程大臣说：“大王，我们能不能跳过内存，直接使用硬盘来操作Java对象？”
IO大臣最近压力最大，已经好几天没合眼了：“不懂别瞎BB，你知道硬盘有多慢吗，比内存慢几万甚至10几万倍，用硬盘怎么干活？还有人类的冯诺依曼体系要求了，数据必须在内存中CPU才能操作。”
线程大臣脑洞打开：“要是发明一个硬盘，容量无限大，速度和CPU一样，那CPU不就直接操作硬盘了，还要内存干什么？！”
国王叹了口气：“别吵了，谁要是发明一个这样的硬盘，我会授予他次Java帝国诺贝尔奖！你们知道人类的摩尔定律吗？集成电路上的晶体管每隔18个月便会增加一倍，性能也会提升一倍。可是这硬盘不行啊，就像手机上的电池一样，一直以来都像老牛拉破车，慢慢吞吞地在发展，这么多年都没有重大的突破。”
IO大臣说：“大王不用灰心，臣最近想出了一个办法，叫做序列化，可以把内存中那些重要的对象转化为二进制文件存储到硬盘上，这样就不怕断电了”
“等到电力恢复以后，还能再让他们回到内存吗？”
“那是自然，我们可以反序列化，把二进制文件变成Java对象，继续在内存中干活。”
国王大喜，颁布命令，要求臣民们都必须学会IO大臣发明的序列化。
2数据库联合酋长国序列化虽然解决了一部分问题，但是臣民们很快发现了它的弱点：效率低。
Java对象少的时候还行，如果需要大规模地对Java对象进行存储、查询的时候那几乎不能用。比如说想选取ag28的所有Prson对象，那就得把所有序列化的Prson对象都装入内存，一个个的比较年龄，这实在是太费劲了。
IO大臣这次也辙了，只好建议国王去国外考察，看看人家遇到这个问题是怎么解决的。
国王放下高傲的身段，派出了多个使团，分别出访了C++,Python,Ruby,C#...等王国。
一个月后，使团陆续返回，带回的消息惊人得一致：使用关系数据库存储大规模数据。
“关系数据库？”国王听说过这个东西，在Java帝国东边的大海上，有一个叫做数据库的岛屿，那里有几个很大的部落，好像有什么Oracl,Db2,SQLSrvr,MySql之类，他们组成了一个联合酋长国。
IO大臣说：“关系数据库就是用类似二维表格的方式来存储数据，臣听说他们从70年代末开始就开始发展，由于有强大的理论基础，像什么关系代数，关系演算，现在发展的非常成熟，可以进行大规模的数据存储和查询，还可以支持我们梦寐以求的事务操作呢。奥对了，他们搞出了一个叫SQL的东西，屏蔽了具体的实现细节和各个数据库之间的差异。”
线程大臣还在记恨IO大臣一个月前的讽刺，马上柔中带刚，皮笑肉不笑地甩出一个炸弹：“这个酋长国看起来挺好啊，只是IO大臣提到他们用二维表格的方式来存储数据，而我们这里是Java对象，好像不太匹配啊。”
国王上钩，向IO大臣发难：“一个是表格的行和列，一个是对象的属性，我们怎么把对象存储到表格中？”
IO大臣胸有成竹地说：“这需要我们的臣民自己写代码，把对象属性变成数据库的行/列，人家别的王国都是这么干的，这种办法还有一个很好听的名称叫Objct-RlationalMapping，只是现在这种Mapping需要我们手工来做罢了，你要想大规模的查询和存储数据，总不能一点代价都不付出吧。”
国王说："那就这么办吧，IO大臣，你去负责和数据库联合酋长国谈判，让他们和我们Java帝国协调一个接口出来，名称就叫......"
IO大臣马上接口：“JavaDatabasConnctivity，简称JDBC，如何？”
“好！就用这个名称，你去谈判一定要坚守住帝国的底线，那就是我们只负责定义接口，具体的JDBC实现必须由各个数据库去提供！你要是搞不定，就别回来见我。退朝！”
3表面风光的EJB半年以后，Java帝国和数据库联合酋长国就JDBC达成一致，双方签署了正式的协议，帝国的臣民们欢欣鼓舞，纷纷开始使用JDBC作为持久化的工具。
可是这JDBC的劣势也很明显：这是一个非常“低级”的接口，程序员需要处理太多的细节，冗余代码太多，写个简单的查询就得一大堆代码伺候，打开connction，创建statmnt,执行sql,遍历rsultst,还得记住关闭connction，要不然会资源泄露......
此时Java帝国正准备向企业级应用进军，需要支持安全，事务，分布式、可伸缩性，高可用性.....等高级功能，这些脏活累活操作系统不想做，应用程序也不想干，那到底扔给谁呢？
帝国一合计，提出了一个令人耳目一新的概念：中间件(middlwar),专门负责底层操作系统和上层应用程序都不愿意做的事情。
帝国充分发挥了制定标准的特长，搞了一套J2EE的规范出来，其中包罗万象，涵盖了大部分企业开发的需求，把通用的，复杂的服务交给中间件提供商去搞定，让开发人员集中在业务逻辑的开发上。
这其中有个标准就是EJB,帝国大肆宣传：只要使用了EJB,再也不用写那些烦人的JDBC代码了，数据的创建，读取，甚至查询都可以用面向对象的风格搞定。更牛的是这些EJB实例可以在一个集群上分布式运行。
在Wbsphr,Wblogic,Jboss等应用服务器的支持和鼓噪下，J2EE在初期热度非凡，帝国横扫企业级市场，别的王国只有看热闹的份。
Java帝国的臣民们享受着外界羡慕的目光，骄傲地使用EJB进行开发，然后扔到应用服务器中执行。
但是其中的辛苦和委屈只有自己知道：开发繁琐，难于测试，性能低下，除了表面的风光，已经剩不下什么了。
4轻量级O/RMapping框架年，帝国有个叫GavinKing的，终于无法忍受金玉其外败絮其中的EJB,自己偷偷另起炉灶，搞了一个O/RMapping的框架出来，名称很有意思，叫做Hibrnat。
冬眠？好像到了冬天让内存的数据进入数据库冬眠，春天来了从冬眠中醒来，再次进入内存工作。
Gavin宣称使用Hibrnat，你可以把Java的属性用声明的方式映射到数据库表，完全不用你操心connction,sql这些细节。
帝国刚开始没在意，觉得这就是个玩具，哪能和强大的EJB相比？
好东西永远都不缺市场，一传十、十传百，Hibrnat很快成了气候，使用简单、灵活，特别是脱离了那些庞大，昂贵的Wbsphr,wblogic容器也能使用。一下子捕获了很多臣民的心。
同年另外一个叫做iBatis的O/RMapping框架也出现了，又拉走了一大批EJB臣民。
年RodJohnson给了EJB以致命一击，他写了一本《ExprtOn-on-OnJ2EEDvlopmntwithoutEJB》，公然宣扬不使用EJB，而要使用更加轻量级的框架，也就是他鼓捣出的Spring。
帝国宣称这是一本禁书，禁止出版发行。可是人的意志总是挡不住历史的潮流，抛弃重量级的EJB,使用更加轻量级的Spring成了大势所趋。
这个Spring不但自己提供了轻量级的访问数据库的方法JDBCTmplat,还能轻松的集成Hibrnat，iBatis等一批工具。慢慢的竟然成为了事实的标准，在帝国流行开来。
5帝国的反击在一次早朝上IO大臣简直是气急败坏了：“陛下，再不禁止Spring,Hibrnat,iBatis的使用，我们的EJB就要被抛弃了。”
国王说：“你禁止得了吗，上次你禁止Rod的那本书，民间的小抄还不是疯狂流行？最近的起义风起云涌，按下葫芦浮起瓢，扑灭了这个，那个又起来了。倒不如任他们去，毕竟也大大地繁荣了我们Java帝国啊”
线程大臣立刻拍马屁：“陛下的心胸真是如同大海般广阔，不过臣倒有一计，既然官方EJB标准抵不过Hibrnat的事实标准，我们要不就把GavinKing招安了算了，为我所用。”
国王表示赞同，命令线程大臣负责招安以及后续工作。
Gavin之前已经加入JBoss部落，现在代表JBoss正式进入JCP,也算是被招安了。他早就有改造官方标准的雄心壮志，带领着帝国的EJB团队推出了EJB3.0，成功地向Hibrnat看齐，其中有些注解简直一模一样,极大的简化了开发。各大厂商重新开始摇旗呐喊，为EJB3.0站台背书。
只是这个EJB3.0有个致命缺陷：没法离开容器（Wbsphr,wblogic,JBoss等）运行，臣民们已经适应了轻量级开发，已经抛弃了重量级的应用服务器，在Spring的带领下，他们再也不需要一个容器来运行EJB了，帝国的这次声势浩大的反击战被化于无形。
不过在EJB3.0中悄悄埋下了一个副产品，叫做JavaPrsistncAPI(JPA),充分地反应了帝国的小算盘，既然我在实现层面无法打败你们，那我就制定我最擅长的标准，用标准整合O/RMapping,一统天下,唯我独尊！
在帝国的力推之下，Hibrnat,EclipsLink，OpnJPA等知名产品都提供了针对JPA的实现，可是帝国的官员们悲哀地发现：现在臣民们又爱上了写SQL语句的MyBatis,唉，这民意真是难以琢磨啊。
国王最终决定改换策略，无为而治，放下官方的架子，只要是有利于帝国的，不再阻碍，任其发展，趁机招安。
帝国反击战就此落幕，持久化工具之战以民间的最终胜利告终。
（完）
来自：码农翻身（）
●本文编号，以后想阅读这篇文章直接输入即可
●输入m获取文章目录
推荐↓↓↓Python编程
更多推荐《18个技术类公众中科白癜风医院爱心公益郑州专治白癜风的医院