都是些寫個自己的一些廢話或者心得,不是什麼技術文章,也完全沒什麼資本給別人扯技術..
前幾天因爲要和同學一起做論壇,前臺希望用AJAX,所以要用到許多XML的轉換.由於牽扯許多轉換,所以當時希望找個框架來完成,由於要先晚上個模型,所以必須拿JAXP,DOM先寫(我不習慣SAX模型),後來發現還是JDOM好用,不過.NET的XML庫來的很爽些.後來開始研究JAXB這個東西.開始看的是1.0,因爲SUN的官網文檔提供的是1.0,只支持從schema到java的影射,必須用工具xjc.感覺雖然很靈活,但是太麻煩了,於是開始自己構思一個轉換的方式,開始的構思是用設計模式裏的一些思想,直接構建成一個不需要工具的轉換類庫,但是問題是xs的類型與JAVA不完全相符合,結果就是一個界於jaxb和bean冷藏的一個不倫不類的中間產物,不靈活.後來找到了jaxb2.0的文檔,真不知道SUN怎麼搞的,官方都不更新的,鬱悶.2.0支持了java到schema的影射,用註釋類型寫bean,可以完全拋開schema構思你的xml文件,最後由schemagen工具生成schema,而且可以由ant來帶工,一切都是相當輕鬆,當然nb寫schema插件也很好用.這樣,jaxb幾乎解決了所有的映射問題.而且還提供了schema的驗證,簡直就是profect,哈哈!又把.net比不見了~嘿嘿!
說了一堆廢話,貌似沒啥有用的,不過還有一些對JAXB結構的理解.首先JAXB有一個明確的目標,就是要讓JAVA影射的XML文件是絕對通用的,追求的是靈活.而我做的架枸卻沒有這樣的目標,沒有明確的目標,再靈活和方便這兩個相背離的方向前猶豫,最後產生的就是不倫不類的東西.再一個,JAXB做到了機制和策略的分離,可以使XML的規範不斷擴大的同時,機制不用改變,既代碼不變,而策略改變,捨得既支持最新標準,而又有辦法支持以前的版本,因爲他使用了於代碼分離的文件去指定機制運行的策略,這也是我完全沒有考慮到的.
再一天時間差不多就可以再開始研究OSGI了,也不知道要多久,沒概念啊,老師沒給個明確的方向,他到底是要實現OSGI,還是要做類似OSGI的框架,還是要用OSGI,還是要OSGI的思想...而且最近覺得IBM的equinox的性能完全不如nb framwork.看了再說吧,沒概念沒有發言權,不過面向服務確實能簡化好多好多好多...思想太牛B了