作為一個曾經(jīng)的Java程序員，已經(jīng)很多年都沒有編碼，但從沒有放棄過對Java和開源的關(guān)心。
最近又有機會開始寫點東西，感覺自己已經(jīng)很遲鈍了，很難有耐心動手寫代碼了。
但是為了盡量縮短自己與現(xiàn)在技術(shù)水平的差距也開始學點“新”東西，比如Struts、Hibernate和Spring。
大多都是停留在摸摸的水平，離實際開發(fā)還有很大的距離。
可能是人老了，變懶了。
一直都在尋找著，更能夠精簡代碼的產(chǎn)品，尤其是使用Hibernate配置了繁瑣OR影射后，
完成一個簡單數(shù)據(jù)庫操作后，真不知道是用它好還是不用它好。
相比之下，一個同事，只在大學上過公共課程C語言程序設計，用不到一周的時間上手Delphi，
并且在不到一個月時間里（中間還因為其他工作出差，中斷過），相對輕松的開發(fā)了一套的程序。
同時對比正在激烈討論的Ruby，微軟的.net都看到了很多Java里面沒有的東西。
原來編程可以這么簡單，也應該這么簡單。
Java有沒有更簡單的方式來保存數(shù)據(jù)，更確切的說是保存對象，DB4O無疑就是這其中的一種。
基于它現(xiàn)在的技術(shù)，有幾個想法
1、數(shù)據(jù)型對象的共享技術(shù)，更多的應該是跨語言的實現(xiàn)，畢竟現(xiàn)在大多數(shù)語言都是面向?qū)ο蟮摹?br>數(shù)據(jù)庫和XML文件在很多時候，在這些不同語言之間充當了一個數(shù)據(jù)傳遞者的角色。
一般數(shù)據(jù)又都是封裝在某個對象里面，與數(shù)據(jù)庫之間OR影射。微軟的SOAP和CLI似乎都是向這個主旨努力。
2、EJB太復雜，雖然買了很多書，但都從來沒有耐性做個測試的樣例。遠程訪問一個對象，必須繼承特定類，
要基于某個協(xié)議，還要配置容器，太困難了。DB4O似乎又提供了另一種思考方式。
3、Session大家用的應該很多，使用的不當對服務器是一種非常大的負擔。還想不到如何減輕服務器的負擔，
但至少可以嘗試使用DB4O來減輕Session也就是容器的負擔。
4、對于3中Session，困難的就是對眾多的臨時數(shù)據(jù)，管理起來太復雜。用過之后就不再使用。
容器自己可以管理Session，清理DB4O中的垃圾數(shù)據(jù)最簡單的方式，就是為DB4O添加一種內(nèi)存數(shù)據(jù)庫模式。
也就是數(shù)據(jù)都放在內(nèi)存里面，管理程序可以清理垃圾數(shù)據(jù)，一次重啟、斷電、系統(tǒng)崩潰，
都可以把這些垃圾數(shù)據(jù)清理掉。
可能還有更多的一些可能，誰又能知道，現(xiàn)在的技術(shù)發(fā)展太快了!
posted on 2006-01-13 22:28
rox 閱讀(685)
評論(1) 編輯 收藏 所屬分類:
雜想