問題タブ [xmldocument]

XML ドキュメントを作成するサンプル アプリケーションを開発し、ドキュメント化された XML を作成して保存しました。アプリケーションはまだ実行されていますが、その XML ドキュメントを削除し、同じアプリケーションを使用して新しい XML を作成しようとしています。のエラーが発生しました

このドキュメントにはすでに「DocumentElement」ノードがあります

既存の XML ドキュメントにノードを簡単に追加できますが、やりたいことは、XML が削除された場合、アプリケーションは同じタグで新しい XML を作成する必要があるということです。

多くの .NET 関数は、XmlWriter を使用して xml を出力/生成します。ファイル/文字列/メモリへの出力は非常に操作です:

場合によっては、結果の Xml を操作する必要があり、それを XmlDocument にロードしたい場合や、他の理由で XmlDocument が必要な場合がありますが、XmlWriter を使用して XML を生成する必要があります。たとえば、XmlWriter のみに出力するサード パーティ ライブラリの関数を呼び出すとします。

できることの 1 つは、xml を文字列に書き込み、それを XmlDocument にロードすることです。

ただし、これは非効率的です。最初にすべての xml 情報を文字列にシリアル化し、次に文字列を再度解析して DOM を作成します。

XmlWriter を指定して XmlDocument を直接構築するにはどうすればよいですか?

C# では、XmlDocument を使用して xml 内のノードを別のノードに置き換えるにはどうすればよいですか。

たとえば、次の xml ファイルを考えてみましょう。

交換する必要があるとしましょう

新しいノードで

Web サービスからの XmlDocument があり、xml のサブセットを使用して Gridview コントロールを作成したいと考えています。残念ながら、必要のない余分なデータが含まれています。したがって、既存の xml ドキュメントのサブセットから新しい XmlDocument を作成したいと考えています。

基本的に、ルート要素として新しい XmlDocument を作成したいと考えています。以下は、元の xml ドキュメントの短縮された例です。

Anthony のコードは私を正しい方向に導くのに役立ちましたが、これが実際に私にとってうまくいったことです。

XmlDocument の単体テストでは、テスト ケースの書き方が少し気になります。

XmlDocument をアサートするために、XmlElements を手動で作成しています。テストする XmlDocument が大きい場合があるため、予想される xmldocument を構築するために多くのコードを記述する必要があります。仕事量は膨大です。

XmlDocument 単体テストのより良い実装はありますか?

次のコードは、「アセンブリから型 'System.Xml.XmlDocument' を読み込めませんでした」というエラーで失敗します。

XmlDocument が存在する System.Xml への参照があります。

私が間違っていることは何ですか？

既存のシステムの一部のコードをリファクタリングしています。目標は、XmlDocument のすべてのインスタンスを削除して、メモリ フットプリントを削減することです。ただし、特定のルールが適用される場合は、XPath を使用して xml を操作します。ドキュメント全体をメモリにロードするクラスを使用せずに XPath を使用する方法はありますか? 他のすべてのインスタンスを XmlTextReader に置き換えましたが、XPath がなく、読み取りが非常に単純であるため、これらのインスタンスのみが機能しました。

一部の XPath は、他のノードの値を使用して決定を下します。たとえば、メッセージ ノードの値は、金額ノードの値に基づいている可能性があるため、一度に複数のノードにアクセスする必要があります。

カスタムオブジェクトを最適化しています-> XMLシリアライゼーションユーティリティ、それはすべて完了して機能しており、それは問題ではありません。

ファイルをXmlDocumentオブジェクトにロードし、すべての子ノードを再帰的に通過することで機能しました。

XmlReader全体をロード/解析する代わりに使用XmlDocumentする方が速いのではないかと考えたので、そのバージョンも実装しました。

アルゴリズムはまったく同じです。ラッパー クラスを使用して、 an と an を処理する機能を抽象化しXmlNodeますXmlReader。たとえば、GetChildrenメソッド yield は子XmlNodeまたは SubTreeを返しますXmlReader。

そこで、重要なデータ セット (約 1,350 の要素を含む 900 KB の XML ファイル) を使用して、両方のバージョンをテストするためのテスト ドライバーを作成しました。

しかし、JetBrains dotTRACE を使用すると、XmlReader実際にはバージョンがバージョンよりも遅いことがわかりますXmlDocument。XmlReader子ノードを繰り返し処理しているときに、読み取り呼び出しに関連する重要な処理がいくつかあるようです。

だから私はこれを尋ねるためにすべてを言います：

と の長所と短所はXmlDocument何XmlReaderですか? また、どのような状況でどちらを使用する必要がありますか?

私の推測ではXmlReader、パフォーマンスがより経済的になり、メモリの消費量が少なくなるファイル サイズのしきい値があると思います。ただし、そのしきい値は 1MB を超えているようです。

ReadSubTree子ノードを処理するために毎回呼び出しています:

このテストは、1 つのレベル (つまり、広くて浅い) で多くのオブジェクトに適用されますXmlReader。つまり、私が扱っている XML は、データ オブジェクト モデル、1 つの親オブジェクトから多くの子オブジェクトなどによく似ています。1..M..M..M

また、解析している XML の構造が事前にわからないため、最適化できません。

私は今学んXmlDocumentでいXDocumentますが、それらの違いや利点を検索しようとすると、役立つものが見つかりません。

XML で Web サービスからデータを受信して​​おり、受信した XML に基づいて構築されたオブジェクトを介してそのデータを使用しています。そのため、セッション内のリクエスト間でそのようなユーザー固有のオブジェクトを保存する必要がある場合があります。XMLDocument を明示的に格納できないことはわかっています (状態サーバー)...そのため、次のようなひどい構造を作成しています。

したがって、暗黙的にxmlを保存しています...オブジェクト全体から必要なプロパティが正確にわからないため、開発中に役立ちます-ピンチでxpathなどを使用して簡単な実験的プロパティを作成できます...

私にとっては快適ですが、そのクラスのプロパティからデータを取得する必要があるたびに、文字列から xmldocument を構築するのは非常に非効率的です。回避策はありますか?) ありがとうございます。