xstream的侷限性
最近做xstream結合hibernate持久化的應用，克服了重重困難，可以讓實體和xml之間相互自由轉換。但從中也發現了xstream應用的一些侷限性。
xstream在轉換有關聯的hibernate實體時，會發生異常痛苦的迴圈嵌入問題，導致不可預期的結果。
問題提出：
比如有兩張通過外間約束的表，假設叫tclass和student表，student有個外間關聯tclass表的主鍵。在做hibernate對映的時候，有兩種選擇：
1、做強關聯，也就是在student類中有乙個tclass的實體屬性。如果是雙向的，在tclass類中還有乙個set，用來記錄班級中包含的學生。大多這種多對一模型會選擇強關聯。這種關聯適用於乙個領域內部的關聯。
2、做弱關聯，也就是僅僅在student類中有乙個tcalssid，用來記錄關聯班級的id屬性。這個時候，資料庫的外來鍵關係是隱含的，沒有sql語法上的外來鍵約束。做對映的時候，兩個表都做單錶對映。這種對映策略常常用於乙個領域外部的關聯。
說明：如果你對領域模型還不熟悉，可以先看看領域模型驅動設計。
這兩種對映僅僅是hibernate程式設計策略的兩個選擇，他們對應的資料表結構是完全一樣的。在student表中僅僅會記錄乙個class表記錄的id。
加入選擇的多對一關聯是強關聯。那麼在轉換student實體物件到student.xml的時候，會將student類的tclass物件一塊轉換。但是往往真正需要的是tclass的id，而非tclass實體，假如做了雙向關聯，tclass實體裡又包含了student的集合，轉換過程就成了乙個相互包含的死迴圈。這當然不是想要的結果。
解決方案：
1、hibernate做弱關聯。
優點：xstream可以直接轉換實體，非常方便。
缺點：打破了領域模型設計的思路，不符合物件導向的設計邏輯，程式設計會很彆扭。
2、重新實現xstream的轉換器com.thoughtworks.xstream.converters.converter介面，實現轉換過程全程控制。
優點：保持了領域模型設計和hibernate的對映策略。
缺點：要自己實現converter介面，很麻煩，乙個實體對應乙個converter介面，工作量加大，容易出錯，一旦實體改變，converter的實現也改變，維護困難。與其這樣，還不如手寫工具將實體轉換為xml。
這兩個解決方案不好分個高低。關鍵是要知道xstream的長處，能做什麼，短處，不能做什麼。在應用之前都應該考慮到揚長避短。這樣不至於過後亡羊補牢，給專案帶來風險。
XStream的侷限性
最近做xstream結合hibernate持久化的應用，克服了重重困難，可以讓實體和xml之間相互自由轉換。但從中也發現了xstream應用的一些侷限性。xstream在轉換有關聯的hibernate實體時，會發生異常痛苦的迴圈嵌入問題，導致不可預期的結果。問題提出 比如有兩張通過外間約束的表，假設...
時代侷限性
時代侷限性的 什麼是時代侷限性？根本原因是理性能力的有限性。一般而言，我們能對問題提出具有一定一般性的解釋並經過一些檢驗，這樣的知識獲取就可以算作理性推知了。至少包括 能理清邏輯 確立因果的解釋是稀有的。不經過思考屬於迷信權威。主要指實踐中的試錯成分。試錯得到的結果有可能缺乏可解釋性。一味堅持過去實...
SQLite的侷限性
sql 92特性方面 正如前面提到的，sqlite不支援sql 92的在很多企業資料庫系統中可用的一些特性。如 外來鍵約束 可解析的，但非強制 很多alter table特性 一些trigger相關的特性 right和full outer join 更新乙個view grant和revoke 你可以...