C#使用递归字典存储xml的缺点是什么

我将xml文件加载到递归字典中，以便可以通过以下方式访问xml文件： Example.xml:

<objects>
<object>
    <id>256</id>
    <objectType>Person</objectType>
    <name>Bob</name>
    <object>
        <id>128</id>
        <objectType>BodyType</objectType>
        <shape>Athletic</shape>
    </object>
    <object>
        <id>1024</id>
        <objectType>Body-Measurements</objectType>
        <height>5'9"</height>
        <weight>155</weight>
    </object>
</object>
<object>
    <id>512</id>
    <objectType>T-Shirt</objectType>
    <object>
        <id>64</id>
        <objectType>Logo</objectType>
        <design>Dragon-Tatoo</design>
        <object>
            <id>64</id>
            <objectType>Design-Color</objectType>
            <color>black</color>
        </object>
    </object>
</object>

示例输出：

RecursiveDictionary RE = loadXML("Example.xml");
Console.WriteLine( ToInt(RE["objects"]["0"]["object"]["id"]) . "\n" );
Console.WriteLine( RE["objects"]["0"]["object"]["0"]["object"]["1"]["height"] . "\n" );
Console.WriteLine( ToConsoleColor(RE["objects"]["1"]["object"]["0"]["object"]["0"]["object"]["color"]).ToString() . "\n" );

128
5'9"
black

ToConsoleColor（）

不需要打印字符串“black”，但在我的实际应用程序中，我会进行转换，然后将控制台颜色设置为

ToConsoleColor（）

返回的枚举值。在本例中，我只是打印ToString（），以显示我将在递归字典中引入XML的效果，然后访问XML文件的细节并将其转换为有用的程序数据类型（在本例中为控制台枚举值）

我的代码在尝试转换任何内容之前检查键/值或标记/值是否存在，并将打印出错误，让我知道我没有处理特定的xml标记以及原因。无论是否使用错误xml，代码都能以最佳方式运行

---

我想知道这样做与使用X路径相比有哪些缺点

XPath很可能比递归字典慢（因为需要编译表达式）

---

但是，我建议使用。代码已经编写和调试，并且具有类似的访问模式。参见

我能想到的缺点是：

• 在我看来，有多个

  […]

  一个接一个，这真是难以理解。您可以很容易地摆脱跟踪，尤其是当项目/xml变得更大时
• 创建这样的词典可能会消耗大量内存。因此，如果不将整个xml加载到这样的结构中，您可能会获得一些空间。使用可能有助于减少此问题

另一方面：如果xml真的保持这么小，XPath可能会变慢，可能会有点过头

---

任何一种方法都会奏效。自己决定什么最合适

这种方法可能没有本质上的错误（尽管存在一些陷阱（见下文）），但我的主要问题是为什么

这是一个常见的问题，许多比我们更聪明的人都遇到过，并提出了解决方案；为什么不使用经过战斗测试的解决方案呢

您不想这样做的几个原因：

RecursiveDictionary RE = loadXML("Example.xml");
Console.WriteLine( ToInt(RE["objects"]["0"]["object"]["id"]) . "\n" );
Console.WriteLine( RE["objects"]["0"]["object"]["0"]["object"]["1"]["height"] . "\n" );
Console.WriteLine( ToConsoleColor(RE["objects"]["1"]["object"]["0"]["object"]["0"]["object"]["color"]).ToString() . "\n" );

128
5'9"
black

你不能查询你的数据

• 与XML相比，这些数据更适合JSON，但请忽略这一点——当您希望基于属性（或者实际上，不是元素名称）进行查询时会发生什么情况

您将失去强类型属性的好处

• 看起来您只是在制作子字典，其键是集合中的索引……这比使用

  XPathNavigator

  并遍历选定节点的子字典容易吗

我清楚地看到了写这样的东西来获得初级程序员的经验的价值，但这不属于prod代码——有太多的潜在问题，而实际功能不足

---

根据我作为程序员的经验，我会给你一些建议：在很长一段时间里，你会想重新发明轮子，因为你可以……学习东西也不错（我在这里呆了一段时间）。当你真的在搭建一个帐篷时，请确保不要自欺欺人地认为你在建造摩天大楼（不要说这就是这里发生的事情；只是一般性的建议）。

你的数据结构不能处理混合内容，也不能保留元素的顺序。这使得它适用于某些XML文档（大致上，那些同样可以用JSON处理的文档），而完全不适用于其他文档。

我认为这更易于阅读。我很好奇您对“潜在”问题和“足够”的示例有何想法。这些术语对我来说是模棱两可的，例如，“足够”有什么资格？潜在的问题是一种直觉，因为您以前见过这样的代码会产生问题？我很感谢你的第一篇帖子，希望你的回复是：）潜在的问题将包括使用你的类时产生的任何bug，而这些bug是你无法通过谷歌搜索到的，因为你试图添加额外的功能。因此，这都是基于您希望添加其他功能的假设。他们会是什么？搜索DOM？这意味着你应该使用现有的图书馆。也许可以弄清楚你是否有一个文本或元素节点？访问属性？这些添加的任何内容都会引发一个警报，说“我在我的头上”，并提示您使用一个完整的库…也就是说，这是一个很棒的练习！事实上，我已经解决了所有这些问题。它们很容易解决。你说得对，没有关于这些问题的文献。在这个案例中，我必须提出问题出现时需要的解决方案。我希望你不要因为总有比你更聪明的人而限制自己；）有时没有，不是因为聪明的人不能理解，而是因为他们可能没有沿着特定的思路走下去。谢谢你详细说明，我对你的意思有更好的解释：）干杯！我会密切注意我的头。现在，这更像是一个实验，或者像你说的一个练习：Dby mix，你是指无序的标签，即与“int”、“float”、“string”、“myCustomObject”等的混合内容相比，还是指“int”、“float”、“string”、“myCustomObject”等的混合内容？不，混合内容是指文档内容，如

一罐蠕虫

。请记住，XML中的M表示“标记”。谢谢。这太完美了！