資料庫時代的終結)

　　以資料庫為核心的軟體時代已經過去，資料庫時代早已結束，當我看到J2EE征途中那麼多人在對象和資料庫之間彷徨痛苦ing的時候，我想我該出來喊一聲了。

　　其實這句話在幾年前肯定有人喊過，因為中介軟體時代的來臨，實際意味著資料庫時代終結，正所謂一山無二虎：如果你重視資料庫，你的J2EE系統就無法完全OO，只有你忽視資料庫，你的系統才有可能完全邁向OO，至於資料庫效能調優等特定功能都可交由EJB容器或O/R Mapping工具實現。

　　很多年前，包括我自己在內的大部分企業程式員都是從資料庫開始我們的職業生涯，最早的是dBase/FoxPro，後來有了 SQL系列資料庫, Oracle將資料庫時代推向了頂峰。

　　每當有一個新項目時，第一步就是首先設計出資料表結構(Table Schema)，然後開始使用SQL語句實現商務邏輯，這種開發模式一直重複，就是後來加入了DelPhI/VB，他們也只是承擔圖形顯示實現，這種C/S結構帶來最大問題是：非常難於維護，修改起來，遷一動百。

　　軟體的生命在於運動，當它需要發展時，最棒的軟體人員如果對他也束手無策，這是誰的悲哀？

　　現在更多人開始接受B/S結構，但是他們中很多人還沒有真正明白為什麼需要B/S結構，B/S代表的多層架構才是真正目的（因此，偽多層的B/S系統遍地皆是）。

　　多層架構實際是將以前系統中的顯示功能、業務運算功能和資料庫功能完全分開，杜絕彼此的耦合與影響，從而實現松耦合和良好的可維護性。

　　一. 從設計上說：由於實現層次完全分離，業務運算功能成為一種中間功能（中介層），它不依賴具體的表現層技術(Jsp/Html applet等)，也不依賴具體資料庫技術（Oracle/SQL Server），業務運算功能運行在J2EE應用伺服器中，當我們的業務運算功能不再依賴資料庫時，是否意味著資料庫已經不是重點？

　　二. 當然，多層結構帶來了效能問題：用戶端訪問資料庫中的資料時，通常需要經過多個層次，非常耗費效能， 如何盡量減少資料庫訪問是J2EE應用系統首要解決的問題，使用預存程序並沒有解決這個問題，預存程序的執行還是屬於後端，並沒有縮短用戶端請求所要經曆的坎坷路途。

　　解決效能問題的根本解決之道是使用對象緩衝，現在， 64位CPU提供的巨大記憶體空間為單台緩衝計算提供了硬體基礎，更重要的是，這種緩衝計算是可伸縮的，通過叢集的緩衝機制（如JBossCache）， 通過增加應用伺服器的數量，可以提高整個商務邏輯層的緩衝計算能力，拋棄過去那種為記憶體斤斤計較的老思維吧。

　　三. 在系統分析之初是否首先需要資料表設計呢？回答是否定的， 以UML為代表物件導向的分析設計方法已經成為強大工具，隨著面向模型驅動分析設計（MDA）的普及， 面向資料庫分析方法正在逐步被拋棄，擁有深厚傳統資料庫分析習慣的程式員必須面對和接受這種挑戰。

　　縱觀整個J2EE系統開發過程，資料庫已經從過去的中心位置降為一種純技術實現，資料庫只是狀態持久化的一種手段（檔案是另外一種實現手段）；什麼是持久化？這是相對於記憶體緩衝狀態而言，持久化就是當記憶體斷電情況下能永久儲存狀態資料，但是如果J2EE應用伺服器是7X24小時叢集運行；幾乎永不當機，是否有持久化的必要呢？

　　很顯然，資料庫已經淪為與作業系統中檔案系統同樣的層面，以它為中心的時代真的結束了，IBM早期將DB2資料庫開源已經強烈向我們昭示這點。

　　對於J2EE初學者來說，儘早拋棄過去的兩種影響：過程語言編程習慣和以資料庫為中心的設計習慣，從全新的物件導向角度(OOA、OOD和OOP、AOP)來設計開發你的J2EE系統，J2EE設計開發三件寶：Model、Patterns和Framework。

　　以上不只是理論，而是我每天正在做的，如果你也是或贊同請廣為傳播，喚醒更多彷徨痛苦的初學者。