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

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

    很久以前沒有Hibernate的時候：

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

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

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

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

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

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

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

   說了這么多，最終只是想說明白這么一句：用恰當的技術做恰當的事情，這真是一個艱難的選擇……，至于未來，更是迷茫，因為我們只是跟隨者，而不是領導者。