persistent layer 第二擊

因為是懶人，所以尋找能順利將object < -> database 轉換的framework就一直是high priority task，
尤其是那些可能可以跟actionscript搭在一起合作愉快的方案更是吸引人。

當然如果你很忙沒時間繼續看下去，那先知道結論就好：目前沒有一個可以直接跟flash配合。

當然由於flash的工程師user base太小，一開始我也不指望會有這種東西，因此直接是從.net與java下手看能不能改過來用。

最初我找到一些關於 O/R mapping的書與文章，裏面教授的是過去二十年來工程師們一直用的手法(也就是雙手萬能的手工藝技巧)，而其中最令我心驚膽顫的一句話就是：

as stated before, 40-60% of the project time were used to handle OR mapping

當然手工藝並不是真的那麼萬惡不赦，很多中小型的案子自已動手或許真的比較快。

但由於類似O/R mapping這樣每天都得處理的routine實在是很煩索的可以，因此java界開始出現一個名為Java Data Object (JDO)的概念，也就是提供一個object 與 database的中介層，這原本只是sun提出的一個spec，但由於很受歡迎，因此很快市場上就出現一狗票的實作商品，理論上可以讓工程師完全不用再手動處理O/R mapping這件事。在所有的JDO-alike的實作裏，OJB算是open source圈內最響叮噹的一個方案。

而這幾年從JDO的概念又衍生出一個更新的persistent 技術，叫做 Hibernate，這個字實在是用的巧妙，讓人發出會心微笑。它有趣的地方在於hibernate原本是指電腦用完但不想關機時，可以按下休眠將ram裏的東西dump到disk上暫存，下次開機時只要把資料讀回ram裏就可以迅速回到可操作狀態(當然現在大家隨便都裝1、2GB的ram，這招不見得會快很多)；而這個字用在persistent方面，很明顯的可以看出工程師是認為 Object 才是”正常的操作狀態”，而存入資料庫(或其它persistent store)只是類似休眠的動作一樣，等將來要用時再取出即可。

從這個類比就不難看出Hibernate想要達到的目標，聽起來確實非常迷人，而更棒的是這個概念已經被port到各種語言，例如C#, php等都有，而且往往還有超過一種的選擇。

以目前調查的結果來看，比較完整的hibernate port都會再包含一層 database abstract layer，讓整個流程變的更有彈性(因為連data store的目標都可以隨便更換)，因此簡單來說，只要想辦法把物件從flash丟回app server，剩下的就交給 C#/php去處理，更讚的一點在於flash remoting可以透過binary的方式傳遞 native actionscript object (例如最常用到的 numeric array與associative array)，因此只要巧妙的玩弄remoting的binary特性，就可以在某種層度上達到Java Value Object甚至某些EJB才能做到的效果。

所以未來幾天有空的時間我會試試把整個流程串起來，看看是否真的可行。

不過使用persistent framework也不是完全沒有缺點，目前已知的問題有：

1、全新的專案比較適合使用，因為通常framework會統包db schema，很難與既有的schema吻合

2、由於db是由framework控管，因此要改東西時往往不是直接殺進db裏動手，而是要透過framework去修正，當架構越大時，成本就越高

3、各種framework都會讓專案的複雜度增加，最後可能變成”拿一個麻煩換另一個麻煩”(意思是：framewokr雖然解決了傳統OR mapping的煩索，但它自已本身可能也會變的很麻煩)

4、大部份php的hibernate port都是小規模私人進行的計畫，因此品質與可靠度只有天知地知他知但我不知，所以用起來要格外小心。

-簡易參考資料-