存儲/序列化對象列表

Question

我會遇到這種情況，即將對象列表作爲屬性存儲在類中的正確方法，以及如何正確地將它們序列化爲XML。

例如，我們有一個TabGroup類，它將包含零個或多個Tabs。

是更好的具有標籤財產清單或標籤引用的列表？只要標籤由獨特的slu identified識別。

List<Tab> 

List<string> 

最終它歸結爲

1. 序列化只是整個TabGroup圖（它將包含所有的標籤和它們的內容）
2. 序列化Tabgroups和標籤indenpendently和維修器材它們分開，通過序列化的Tabgroup圖中的slug列表引用。

的1最顯着的優點：

• Tabgroup在其整體堅持一個序列化的文件，保持數據存儲結構簡單。

的1最值得注意CON：

• 一個更新到包含選項卡中的一種製成每次Tabgroup必須更新（reserialized）太。

的2最顯着的優點：

• 更新標籤不需要Tabgroup的reserialization（至少在不添加任何物質或刪除），因爲引用保持不變;所以只有更新後的Tab必須重新序列化。

的2最引人注目CON（這就是爲什麼我寫這個的主要原因）

• 個人標籤文件可以在文件存儲被刪除，但引用的名單仍然是相同的，所以錯誤/查看/呈現Tab組時發生異常;複雜的邏輯將不得不實施，以呈現出類似「Tab以不受支持的方式從數據存儲區中移除，並將其從Tabgroup中移除？」

你有什麼建議來解決這個問題？我會接受涵蓋廣泛含義的答案。請注意，我們在這裏只談論XML持久性，顯然在SQL中，我們沒有多少實驗空間，因爲Tabgroups和Tabs通常會在單獨的表中（它們之間具有一對多關係）。

Answer 1

除非你有一些非常令人信服的理由，數據存儲複雜的是一個好主意，你應該去通常與保持簡單。其次，在閱讀整篇文章兩次後，我不太明白你的問題是什麼。

我不太清楚你的問題是什麼，但如果你問你的設計是否應返回List<Tab>或List<string>其中每個字符串代表一個鏈接到一個選項卡，然後我會主張List<Tab>。如果加載是一個問題，您可以延遲加載除ID之外的整個結構或用於鏈接的任何內容。通常，它只是讓事情變得更容易，直接從對象中獲得所需內容，而不必單獨獲取鏈接列表並加載所有鏈接。

沒有關於實際問題的更多信息，我懷疑任何人都可以幫助你，而不是基於假定的情況給予一些長期的優點/缺點。