我目前完成了一個需要使用C++將數據庫信息寫入XML的項目的兩個階段之一。雖然使用第三方工具來進行XML標籤和數據的實際格式化，但我仍然需要設計一個模型以及業務邏輯來獲取數據庫表並將它們映射到XML結構中。有沒有更好的設計模式/方法使用？
爲此，我最終爲每個XML結構創建了一個單獨的類，導致了大量的類（〜75）。每個類都具有如何讀取關聯表的知識，並通過第三方工具將自身序列化爲XML。最後，系統運行良好（按時和預算），輸出錯誤非常容易找到。
第二階段幾乎完全相同，但不是格式化文本，而是二進制數據。因此，雖然我仍在考慮使用第一階段中使用的相同策略，但我想問，是否會有更好的方法或設計模式來解決這個問題？尤其是，由於第一階段的某些XML類別中存在大量的依賴關係，因此單元測試非常困難。
的其他的想法，也可能適合：
當性能不是問題，也可以使用通用的數據容器。通用數據容器可以指定一個節點（如XML節點或對象，甚至是表格條目）並只存儲這樣一個容器。
這樣，~75類可以被一個或少數幾個替代。像序列化這樣的服務也可以通用的方式提供。
因此，不同的實例可以扮演不同類別仍然扮演的角色。
盡我所知，所使用的數據基元相當直接且有限。所以這可以實現得相當簡單。
我認爲你釘了它與這個答案Juergen頭，謝謝。 – Matthew 2010-01-15 20:50:51
構建一個生成器 - 如果可能的話 - 自動生成類。
生成器當然可以由指定數據如何存儲在數據庫中的規範語言提供。
這涉及到如何儘可能均勻地存儲數據。
更好的是（在開發效率的意義上 - 不是在教育/模式學習意義上）：使用已經存在的開發工具（開源或商用開發工具）。
編輯： 有幾個圖書館/框架應該做這種工作。儘管我讀過書，但還是使用了一個圖書館 - 但它接近它並沒有做太多。有持久性層/框架來從數據中寫入OO數據。 XML數據不是別的面向對象的表示。可能是，你已經編寫了一個圖層來達到完整的目標，但使用第三方產品可能是有益的（在許多情況下）。
您正在描述Visitor模式的經典應用。您需要兩個目的來遍歷對象模型，一次輸出XML，另一次輸出二進制數據。這在gang of four's book中有很好的解釋。
模型的每個元素都必須接受一個識別類型的訪問者（通常爲IVisitor），然後它會調用此訪問者通常調用的方法AcceptVisitor。這是將對象轉換爲XML，二進制數據，可打印格式或其他方法的方法。它也可能引導訪問者訪問子對象等等。然後你編寫一個實現IVisitor的XmlVisitor，並用它「訪問」你的結構 - 結果是XML。相似地，您可以通過BinaryVisitor「訪問」並獲得二進制輸出。
我從不抱怨得到-1s，但很高興知道爲什麼如果答案有問題......有人想詳細說明一下嗎？ – 2010-01-15 16:12:44
偉大的答案大衛，但在這種情況下，我無法重用階段一中使用的原始〜75類，因爲階段二中的數據結構略有不同。如果我需要更改第一階段的輸出格式，我將繼續保留您的建議以供進一步使用。 – Matthew 2010-01-15 16:52:33
嗨大衛，訪問者模式是一個好主意，但至少它不會幫助從SQL數據庫讀取數據的問題。在這種情況下，這不是一個「經典應用程序」。我沒有看到，如果OP真正理解他的問題，因爲他寫道，如果XML將是他的內部表示。在這種情況下，首先得到他的內部代表是正確的，而不是考慮訪客模式（我會預見不是一個更好的實現，但它可能會更糟糕......） – Juergen 2010-01-15 16:54:58
有趣的問題......你爲什麼選擇使用C++和那個工具？ - 只是好奇。 – 2010-01-15 15:58:31
我正在使用C++，因爲原始系統在SPARC系統上以C++編碼，需要將其集成到工具集中。我應該注意到，階段二的類和數據結構與階段一不同。所以我不能重複使用它們中的任何一個。因此，爲什麼我正在尋找一種方法/模式來減少與第一階段相比我必須編寫的新代碼的數量。 – Matthew 2010-01-15 16:32:32
您好馬修，它現在「聞起來」更多，現在是一個很好的應用程序的發電機或至少一個框架，簡化了大量的類的實施...也從您的描述，我仍然不確定，如果你得到你的內部代表權。我認爲這應該完全獨立於XML - 只有某些作者應該完成XML /二進制部分。正如大衛所寫，訪問者會很棒 - 但它也可能是基類，特殊界面等的一部分。 – Juergen 2010-01-15 16:58:48