O/X Mapping 的故事續集的續集

多年前就在部落格上寫過O/X Mapping的故事，及其續集。O/X Mapping並不是一個常用的術語，只是借用了O/R Mapping的思路，自己對XML序列化的一個別稱。

沒想到的是，這麼多年來，關於O/X Mapping的故事一直在延續。

每次當我為一個新項目搭建代碼架構的時候，或多或少，都在這個XObject類庫裡面增加些新特性，來滿足新的需求。儘管在大多數項目裡面，沒有人願意把對一些基礎類庫的修改或重構的工作，列在進度表上，因為老闆總是目標導向的。好像只有那些技術發燒友，才會從老闆給定的時間裡面，偷偷地榨取一部分，來進行一些最佳化和重構，以便在未來更長的一段時間裡，用一種更加舒暢的心情進行編程。因此，這些重構就像外科手術一樣，不僅要快，而且每一步都必須小心翼翼，免得耽誤進度。

在軟體生命週期裡，大部分的時間都是在做維護，隨著需求的變化和團隊的發展，代碼會慢慢變得雜草叢生，直到難以維護，推倒重來。我曾一度相信，在項目不忙的時候，會有人站出來說，咱們專門花一段時間來重構吧。但多年來，發現這隻是個傳說。人都是有惰性的，也許只有在時間緊壓力大的時候，才會有重構的動力，而且往往這個時候找到的解決方案才是最簡單，最沒有過度設計的。所以，就讓我們把這種悄悄地重構進行到底把，終有一天，你會為自己的代碼感到自豪。

之前的一些小項目，曾經試過把XObject的底層全部換掉，替換成WCF中的DataContractSerializer，代碼量一下小了很多。而且當時發現，它也能對XML Schema的版本變化也有一定程度的相容性。雖然沒有做過效能的比較，但它用做PRC過程中的資料交換，還算是個不錯的選擇。但如果用來做設定檔的讀寫，有個很討厭的毛病，就是產生大量的xml命名空間的定義，這對XPath的支援，以及手工維護設定檔帶來極大的不便。為瞭解決這個問題，必須在每個對象上面用Attribute來重新聲明xml命名空間，很辛苦，也很容易出錯。

後來想到System.Xml命名空間裡的XmlSerializer，這個東西不像DataContractSerializer那樣針對資料轉送進行過定製，預設不產生xml命名空間，而且產生的xml帶有換行縮排，看起來是用做設定檔讀寫的首選。但可怕的是，同一段代碼在WinForm裡面啟動並執行好好的，在Windows Service裡面，XmlSerializer還原序列化時就報找不到類型的異常：因為生產環境中，程式通常是以外掛程式載入到Windows Service的方式運行，難道XmlSerializer還原序列化時候預設跑到system32下去找這些類型了？在網上一搜，發現還有人說XmlSerializer會產生記憶體泄露。幸虧單元測試做得及時，在程式中調用XmlSerializer的方法上，趕緊標上個Obsolete，小心使用。

最終還是選擇了WCF的對象序列化機制，來做XObject的增強。這樣，針對設定檔讀寫的部分，還是用之前自己編寫的反射機制來實現，避免那些無聊（至少對設定檔來說）的命名空間，還可以對XML序列化還原序列化過程進行精確的白盒控制；針對資料交換的部分，就用WCF來做JSON序列化和還原序列化，畢竟時至今日，在很多領域XML已經慢慢被JSON取代。

但XObject最早是在.Net1.1時代寫的，後來2.0有了泛型，做了些封裝，但集合類型還是依賴於最古老的CollectionBase，鬱悶的是WCF不認這個，它只認List<T>。於是，唯一的辦法就是把原來XObject實現中基於繼承的機制拿掉，改成類似修飾器模式的彙總機制，這樣需要序列化的對象，就能同時使用WCF和原來XObject的序列化功能了。而且所有這些改動都可以封裝到原來的XObject和XCollection基類裡面，上層應用絲毫不用修改。

另外，在單元測試中發現，之前自己做的XML序列化工作並沒有白費，精確的白盒控制不僅可以帶來很多意想不到的好處，也能克服微軟類庫的一些缺點。比如WCF序列化，不管是XML還是JSON，都不能很好地處理這樣的XML Schema，其中的MyElement都會被忽略掉。如果某個第三方定義的奇怪的XML Schema裡麵包含這樣的結構，估計只能靠我們自己搞定了。

<MyCollection>
  <MyElement></<MyElement>
  <MyCollectionItem></MyCollectionItem>
  <MyCollectionItem></MyCollectionItem>
  <MyCollectionItem></MyCollectionItem>
</MyCollection>

--

XML檔案是機器讀的，不是人讀的，你是人的話，就不要去讀XML：這有點偏激，卻是O/X Mapping構思之初的一個基本假設。也許只要這個假設存在，O/X Mapping的故事還會不斷延續和豐富下去。

十分厭惡傳統的Java開發裡面，大量的設定檔的手工修改工作，這樣的開發方式，低估了設定檔對程式行為的影響：憑什麼代碼修改就要通過測試才能上線，設定檔就可以隨便讓人修改。