最近在做一個很小的項目的功能改進(jìn)，小小的項目中原來連接的是MySQL數(shù)據(jù)庫，現(xiàn)在需要新連接一個數(shù)據(jù)庫（Oracle），僅僅從一張表查詢數(shù)據(jù)即可，沒有添加、修改、刪除等等功能。本來這個小小的項目中用的是Hibernate，現(xiàn)在又要增加一個數(shù)據(jù)庫連接，覺得配置起來有點麻煩，忽然想起來，我干嗎還要用Hibernate呢，直接用JDBC不也挺好使么，想了便做，果然寫起JDBC來，很是快捷，一會就搞好了。

    做好了以后，忽然覺得有點迷茫，感覺不用Hibernate不也挺好的么，咱為什么現(xiàn)在開口閉口都是Hibernate呢，于是便有了今天的題目。

    很久以前沒有Hibernate的時候：

    第一階段：我們寫程序都是直接用JDBC，甚至在JSP頁面中直接去createConnection，然后執(zhí)行查詢，輸出到頁面。

    第二階段：后來覺得每次都是創(chuàng)建一個連接，好像效率不高，于是看了別人的介紹，要用數(shù)據(jù)庫連接池，好的，那便用數(shù)據(jù)庫連接池吧，每次都從pool中獲得一個Connection，然后查詢數(shù)據(jù)。

    第三階段：用了連接池，還是效率不高，那怎么辦呢？用緩存吧，自己實現(xiàn)緩存？可以，也可以用開源的緩存框架。

    第四階段：到了OO大流行的時代了，一切都要OO，恰逢Hibernate降臨人世，于是一切都用Hibernate來實現(xiàn)了，其實同期還是有不少其它ORMAP框架的，比如（TOPLINK、JDO、IBatis等，IBatis國內(nèi)用的還比較多，另外兩個好像用的比較少）。

    第五階段：忽然EJB大流行，事務(wù)的概念被廣為傳播（并不是原來沒有事務(wù)的概念，只是實現(xiàn)起來比較麻煩），借助EJB的廣為傳播，Spring+Hibernate的組合也慢慢占據(jù)了大半市場。此時事務(wù)用Spring AOP的聲明式事務(wù)來解決，緩存可以用開源的緩存框架（已經(jīng)和Hibernate無縫集成了），數(shù)據(jù)庫連接池也是通過配置的方式在SpringContext.xml文件中配置，貌似一切都很完美。

    真的到了第五階段，一切是不是真的完美了呢，如果一個很小的應(yīng)用，需要從好幾個數(shù)據(jù)庫查詢數(shù)據(jù)，但是每個數(shù)據(jù)庫僅需要查詢那么一兩張表的數(shù)據(jù)，偶爾添加、刪除幾條數(shù)據(jù)，數(shù)據(jù)量也不大，此時我們是不是還用第一階段的方式會更好呢，好像有時配置多數(shù)據(jù)源也不是那么方便的事情?；蛘呤褂肧pring中的JDBCTemplate，貌似也不錯。

    再往后看，難道Spring+Hibernate的組合就天下無敵了么？難道就沒有新的框架了么？前段時間，JavaEye上關(guān)于充血模型、貧血模型的討論吸引了多少眼球，以后是不是會有這么一個框架用于實現(xiàn)充血模型呢？

   說了這么多，最終只是想說明白這么一句：用恰當(dāng)?shù)募夹g(shù)做恰當(dāng)?shù)氖虑?，這真是一個艱難的選擇……，至于未來，更是迷茫，因為我們只是跟隨者，而不是領(lǐng)導(dǎo)者。