我使用C++編寫的多線程消息處理應用程序。應用程序接收xml消息，執行一些操作，並且如果需要可以將xml消息發佈到另一個服務。在C++中處理xml的好方法
目前，該應用程序的工作原理是解析消息時解壓縮數據，並在解析過程中對該消息執行一些操作。這對我來說似乎很差。我有機會創建一個替代方案，並且正在考慮我可以使用的方法。
我想到的一種方法是將xml數據序列化爲數據對象，一旦完成，就會根據需要提取和處理數據。缺點是我必須爲我處理的每個不同xml消息構建一個新類（可能在30個左右），但是這種方法似乎比我現在擁有的更清晰。
有沒有比這更好的方法？還應該提到的是，任何在美國以外開發的代碼庫都不可能獲得批准。
目前，該應用程序的工作原理
那麼你到底是什麼固定？
不要修復沒有損壞的東西。
「如果沒有損壞，它沒有足夠的功能。「^^ – 2011-03-29 07:34:54
@Zeta，OP明確指出這是創建替代品的機會 - 聽起來像是政府的IT項目..） – Nim 2011-03-29 07:36:39
重構是什麼？它是一個錯誤，是改變軟件的唯一原因嗎？應用程序解析並在同一時間執行操作，這在兩個不同的進程之間創建了一個人工依賴關係，它可以很好地處理異常並且將來也會限制代碼的重用，最後正確的決策可能仍然是做沒有什麼，但是在我看來，值得努力去思考它 – 2011-03-29 09:56:29
通常有兩種解析XML的方法：DOM和SAX。 DOM建立一個文檔對象模型（就像你提出的那樣），而SAX在分析過程中訪問文檔的一部分時調用回調函數。免費的着名的libxml2庫支持兩種解析方法。
通常，SAX方法（即使用在訪問文檔時執行的回調函數）使用較少的內存，並且可能導致較低的最終用戶延遲，因爲您可以立即開始處理，而不必等待整個文檔已被解析和建立。
您的程序是多線程的事實是一個紅鯡魚。只要您總是將一個對象傳遞給每個回調函數，並且該線程之間不共享該對象，則可以安全地在多個不同的線程中使用多個不同的此類對象執行此操作。使用諸如libxml2之類的標準庫來進行解析也是從重用的角度來看的。
可能有一些設計決策導致了這種方法（比如說，使用SAX模型比使用DOM模型更快），後者需要解析整個消息，與前者一樣，您可以在您使用數據回電時作出決定。
在做出任何改變之前，我會先嚐試理解這些內容，其次除了保持繁忙外，還有真正的商業需求嗎？如果沒有，繼續前進，並做其他的事情......
確實，該應用程序「有效」，從這個意義上說，沒有「業務需求」。但是，這個應用程序正在不斷增長，並且不斷增加新的功能和類型的消息。正如另一張海報所說，這是一個重構練習，我試圖在解析邏輯和從輸入數據中的變化中產生的執行邏輯之間提供分離。處理類型（SAX或DOM）對我來說無關緊要，因爲這種類型的應用程序具有良好的清潔架構。 – JasonK 2011-03-30 16:00:21
這個「非U.S」代碼規則來自哪裏？世界各地都有很多優秀的圖書館開發：只能使用美國地圖上的圖書館，這看起來很奇怪。 – ereOn 2011-03-29 09:46:11
這是政府客戶的規定。 – JasonK 2011-03-30 17:21:27
使用非美國代碼可能更便宜，但使用與特定版本掛鉤的副本，並在將代碼納入代碼庫之前對其進行審覈（並在每次更新到新版本時進行審覈）。儘管審計需要時間，但可能比自己實施審計所需的時間要少。 （也就是說，假設你可以說服你的政府客戶以這種方式進行審計就足夠了）。 – 2011-04-01 01:48:05