2

XElementからを削除する必要がありXDocumentます。

問題は.Remove()、 myXDocumentが と同じではないため、 をそのまま使用できないことXElementです。

非常に重要な事実はパフォーマンスです。

シナリオ: があり、XDocument docSourceこれを にコピーしXDocument docます。のノードを選択し、docSourceこのノードを で削除したいと考えていdocます。

これまでのところ、この回避策を使用しています (同じ親名を取得した場合、間違ったノードも削除される可能性がありますが、これは今のところ問題ではありません):

    private static XNode actualNode;
    private static void RemoveNode(XDocument doc)
    {
        doc.Root.Descendants(((XElement)actualNode).Name.LocalName)
                             .Where(e => actualNode.Parent.Name.LocalName.Equals(e.Parent.Name.LocalName))
                             .Remove();
    }

これを行うより良い方法はありますか？そして特により速い方法は？私の XDocument には 1000 行ほどあります。

4

2 に答える 2

3

既存の名前ベースのアプローチを行うより良い方法は次のとおりです。

doc.Root.Descendants(actualNode.Parent.Name)
        .Elements(actualNode.Name)
        .Remove();

他のことは別として、それはより簡単です-そして、ローカル名だけを使用しません. (要素が実際に異なる名前空間にある場合は、個別に IMO を考慮する必要があります。)

しかし、これはまだ要素を識別する方法として「要素名と親名」を使用しているだけです。要素をより確実に識別するものは他にありますか? 何かの属性？どのような種類の要素が見つかるかについて、実際に何らかのアイデアを持っていると思います。

私の XDocument には 1000 行ほどあります。

そうすれば、とにかく瞬く間に速くなるはずです。これがパフォーマンスの問題を引き起こしているという兆候は実際にありますか?

考慮すべきもう1つのこと：

シナリオ: XDocument docSource があり、これを XDocument doc にコピーします。docSource のノードを選択し、ドキュメント内のこのノードを削除したいと考えています。

最初にノードをコピーすることを避けない理由はありますか?

于 2013-06-06T11:54:07.593 に答える
1

あなたが正しく言ったように、Parent.Name.LocalName だけに依存すると、似たような名前の親が存在する場合に誤った子ノードを削除してしまう可能性があります。

子ノードを削除する前に親ノードの繰り返しを検証すると、この問題を解決できます。

ノードを配列/リストにロードすることで、精度を達成できるはずです。次に、正確な親ノードの位置を見つけることができます。しかし、パフォーマンスが向上しないのではないかと心配しています。

たとえば、「XZY」を持つ 3 つの親ノードがあるとします。ユーザーは 2 つの親ノードを選択します。したがって、親インデックスは 1 になります (インデックスが 0 で始まると仮定します)。そのため、親インデックス 1 の下の子のみを削除する必要があります。

お役に立てれば。

于 2013-06-06T12:13:07.163 に答える