持久化：Java帝國反擊戰
1 斷電的威脅
強大的Java帝國自成立一來， 一直順風順水， 可是外人不知道的是，帝國也有個致命的弱點， 那就是害怕一種叫做“斷電”的攻擊。
每次攻擊來臨， 帝國辛辛苦苦制造出Java對象都會瞬間死亡， 變成孤魂野鬼，在電腦里四處游蕩，最終悄無聲息地消失在空氣中。
這是沒有辦法的事情， 帝國生存所依仗的Java對象都必須在內存中才能工作， 而內存最怕“斷電” !
這件事情變成了國王的一件心病，茶不思飯不想。
某日朝會， 國王又把這個難題拋給了下面戰戰兢兢的各位大臣。
線程大臣說： “大王， 我們能不能跳過內存，直接使用硬盤來操作Java對象?”
IO大臣最近壓力最大，已經好幾天沒合眼了：“不懂別瞎BB，你知道硬盤有多慢嗎，比內存慢幾萬甚至10幾萬倍， 用硬盤怎么干活?還有人類的馮諾依曼體系要求了，數據必須在內存中CPU才能操作。 ”
線程大臣腦洞打開：“要是發明一個硬盤，容量無限大，速度和CPU一樣，那CPU不就直接操作硬盤了，還要內存干什么?!”
國王嘆了口氣： “別吵了，誰要是發明一個這樣的硬盤，我會授予他100次Java帝國諾貝爾獎! 你們知道人類的摩爾定律嗎?集成電路上的晶體管每隔18個月便會增加一倍， 性能也會提升一倍。可是這硬盤不行啊， 就像手機上的電池一樣，一直以來都像老牛拉破車，慢慢吞吞地在發展，這么多年都沒有重大的突破。”
IO大臣說：“ 大王不用灰心， 臣最近想出了一個辦法，叫做序列化， 可以把內存中那些重要的對象轉化為二進制文件存儲到硬盤上，這樣就不怕斷電了”
“等到電力恢復以后，還能再讓他們回到內存嗎?”
“那是自然， 我們可以反序列化，把二進制文件變成Java對象，繼續在內存中干活。”
國王大喜，頒布命令，要求臣民們都必須學會IO大臣發明的序列化。
2 數據庫聯合酋長國
序列化雖然解決了一部分問題， 但是臣民們很快發現了它的弱點： 效率低。
Java對象少的時候還行，如果需要大規模地對Java對象進行存儲、查詢的時候那幾乎不能用。 比如說想選取 age > 28的所有Person對象， 那就得把所有序列化的Person 對象都裝入內存， 一個個的比較年齡， 這實在是太費勁了。
IO大臣這次也轍了， 只好建議國王去國外考察，看看人家遇到這個問題是怎么解決的。
國王放下高傲的身段， 派出了多個使團，分別出訪了C++, Python, Ruby, C#... 等王國。
一個月后，使團陸續返回，帶回的消息驚人得一致： 使用關系數據庫存儲大規模數據。
“關系數據庫? ” 國王聽說過這個東西，在Java帝國東邊的大海上，有一個叫做數據庫的島嶼，那里有幾個很大的部落，好像有什么Oracle, Db2, SQLServer ,MySql 之類， 他們組成了一個聯合酋長國。
IO大臣說： “關系數據庫就是用類似二維表格的方式來存儲數據，臣聽說他們從70年代末開始就開始發展， 由于有強大的理論基礎，像什么關系代數，關系演算， 現在發展的非常成熟，可以進行大規模的數據存儲和查詢，還可以支持我們夢寐以求的事務操作呢。 奧對了，他們搞出了一個叫SQL的東西，屏蔽了具體的實現細節和各個數據庫之間的差異。”
線程大臣還在記恨IO大臣一個月前的諷刺，馬上柔中帶剛，皮笑肉不笑地甩出一個炸彈： “這個酋長國看起來挺好啊， 只是IO大臣提到他們用二維表格的方式來存儲數據， 而我們這里是Java對象，好像不太匹配啊。”
國王上鉤，向IO大臣發難： “ 一個是表格的行和列，一個是對象的屬性， 我們怎么把對象存儲到表格中?”
IO大臣胸有成竹地說： “這需要我們的臣民自己寫代碼，把對象屬性變成數據庫的行/列， 人家別的王國都是這么干的， 這種辦法還有一個很好聽的名稱叫Object-Relational Mapping， 只是現在這種Mapping 需要我們手工來做罷了， 你要想大規模的查詢和存儲數據，總不能一點代價都不付出吧。 ”
國王說： "那就這么辦吧， IO大臣，你去負責和數據庫聯合酋長國談判，讓他們和我們Java帝國協調一個接口出來，名稱就叫......"
IO大臣馬上接口： “Java Database Connectivity ，簡稱JDBC，如何?”
“好! 就用這個名稱， 你去談判一定要堅守住帝國的底線， 那就是我們只負責定義接口， 具體的JDBC實現必須由各個數據庫去提供! 你要是搞不定，就別回來見我。 退朝!”
3 表面風光的EJB
半年以后，Java帝國和數據庫聯合酋長國就JDBC達成一致，雙方簽署了正式的協議， 帝國的臣民們歡欣鼓舞， 紛紛開始使用JDBC作為持久化的工具。
可是這JDBC的劣勢也很明顯： 這是一個非常“低級”的接口， 程序員需要處理太多的細節， 冗余代碼太多，寫個簡單的查詢就得一大堆代碼伺候，打開connection，創建statement, 執行sql, 遍歷resultset, 還得記住關閉connection，要不然會資源泄露......
此時Java帝國正準備向企業級應用進軍， 需要支持安全，事務，分布式、可伸縮性，高可用性.....等高級功能， 這些臟活累活操作系統不想做， 應用程序也不想干，那到底扔給誰呢?
帝國一合計，提出了一個令人耳目一新的概念： 中間件(middleware ) , 專門負責底層操作系統和上層應用程序都不愿意做的事情。
帝國充分發揮了制定標準的特長， 搞了一套J2EE的規范出來，其中包羅萬象，涵蓋了大部分企業開發的需求， 把通用的，復雜的服務交給中間件提供商去搞定， 讓開發人員集中在業務邏輯的開發上。
這其中有個標準就是EJB, 帝國大肆宣傳： 只要使用了EJB, 再也不用寫那些煩人的JDBC代碼了，數據的創建，讀取，甚至查詢都可以用面向對象的風格搞定。 更牛的是這些EJB實例可以在一個集群上分布式運行。
在Websphere, Weblogic, Jboss等應用服務器的支持和鼓噪下，J2EE在初期熱度非凡， 帝國橫掃企業級市場，別的王國只有看熱鬧的份。
Java帝國的臣民們享受著外界羨慕的目光，驕傲地使用EJB進行開發，然后扔到應用服務器中執行。
但是其中的辛苦和委屈只有自己知道： 開發繁瑣，難于測試，性能低下，除了表面的風光，已經剩不下什么了。
4 輕量級O/R Mapping框架
2001年，帝國有個叫Gavin King的，終于無法忍受金玉其外敗絮其中的EJB, 自己偷偷另起爐灶，搞了一個O/R Mapping的框架出來， 名稱很有意思，叫做Hibernate。
冬眠? 好像到了冬天讓內存的數據進入數據庫冬眠， 春天來了從冬眠中醒來，再次進入內存工作。
Gavin宣稱使用Hibernate ，你可以把Java 的屬性用聲明的方式映射到數據庫表， 完全不用你操心connection, sql 這些細節。
帝國剛開始沒在意，覺得這就是個玩具，哪能和強大的EJB相比?
好東西永遠都不缺市場，一傳十、十傳百，Hibernate很快成了氣候， 使用簡單、靈活，特別是脫離了那些龐大，昂貴的Websphere, weblogic容器也能使用。 一下子捕獲了很多臣民的心。
同年另外一個叫做iBatis的O/R Mapping框架也出現了， 又拉走了一大批EJB臣民。
2004年 Rod Johnson 給了EJB以致命一擊， 他寫了一本《Expert One-on-One J2EE Development without EJB 》 ， 公然宣揚不使用EJB， 而要使用更加輕量級的框架，也就是他鼓搗出的Spring。
帝國宣稱這是一本禁書，禁止出版發行。可是人的意志總是擋不住歷史的潮流， 拋棄重量級的EJB, 使用更加輕量級的Spring成了大勢所趨。
這個Spring 不但自己提供了輕量級的訪問數據庫的方法JDBCTemplate, 還能輕松的集成Hibernate， iBatis 等一批工具。慢慢的竟然成為了事實的標準， 在帝國流行開來。
5 帝國的反擊
在一次早朝上IO大臣簡直是氣急敗壞了：“陛下，再不禁止Spring ,Hibernate ,iBatis的使用， 我們的EJB就要被拋棄了。”
國王說： “你禁止得了嗎，上次你禁止Rod的那本書，民間的小抄還不是瘋狂流行? 最近的起義風起云涌，按下葫蘆浮起瓢，撲滅了這個，那個又起來了。倒不如任他們去，畢竟也大大地繁榮了我們Java帝國啊”
線程大臣立刻拍馬屁： “陛下的心胸真是如同大海般廣闊，不過臣倒有一計， 既然官方EJB標準抵不過Hibernate的事實標準， 我們要不就把Gavin King 招安了算了，為我所用。”
國王表示贊同，命令線程大臣負責招安以及后續工作。
Gavin 之前已經加入JBoss部落，現在代表JBoss正式進入JCP,也算是被招安了。 他早就有改造官方標準的雄心壯志， 帶領著帝國的EJB團隊推出了EJB3.0 ， 成功地向Hibernate 看齊， 其中有些注解簡直一模一樣,極大的簡化了開發。 各大廠商重新開始搖旗吶喊，為EJB3.0站臺背書。
只是這個EJB3.0有個致命缺陷： 沒法離開容器(Websphere, weblogic ,JBoss等)運行， 臣民們已經適應了輕量級開發， 已經拋棄了重量級的應用服務器，在Spring 的帶領下，他們再也不需要一個容器來運行EJB了， 帝國的這次聲勢浩大的反擊戰被化于無形。
不過在EJB3.0中悄悄埋下了一個副產品，叫做Java Persistence API(JPA), 充分地反應了帝國的小算盤， 既然我在實現層面無法打敗你們，那我就制定我最擅長的標準， 用標準整合O/R Mapping, 一統天下, 唯我獨尊!
在帝國的力推之下， Hibernate , EclipseLink ，OpenJPA等知名產品都提供了針對JPA的實現， 可是帝國的官員們悲哀地發現： 現在臣民們又愛上了寫SQL語句的MyBatis, 唉，這民意真是難以琢磨啊。
國王最終決定改換策略，無為而治，放下官方的架子，只要是有利于帝國的，不再阻礙， 任其發展，趁機招安。
帝國反擊戰就此落幕，持久化工具之戰以民間的最終勝利告終。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
