C#使用递归字典存储xml有什么缺点答案

【问题标题】：C# What are the disadvantages to using a recursive dictionary to store xmlC#使用递归字典存储xml有什么缺点
【发布时间】：2015-12-28 20:41:58
【问题描述】：

我将 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>

使用递归字典的示例 C# 代码：

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() 不需要打印出字符串“黑色”，但在我的真实应用程序中，我会进行转换，然后将控制台颜色设置为 ToConsoleColor() 返回的枚举值。在这种情况下，我只是打印 ToString() 以显示我想要在递归字典中拉入 XML 然后访问 xml 文件的详细信息并将它们转换为有用的程序数据类型的效果（在这个控制台枚举值的大小写）。

我有代码可以在尝试转换任何内容之前检查键/值或标签/值是否存在，并且会打印出错误，让我知道我没有处理特定的 xml 标签以及出于什么原因。代码尽可能地运行，无论是否出现错误 xml。

我想知道这样做与使用 X-Paths 相比有什么缺点。

【问题讨论】：

我觉得这个dynamic version 更易读

标签： c# xml dictionary recursion

【解决方案1】：

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

这是一个常见问题，很多比我们任何一个都聪明的人都遇到过并想出了解决方案；为什么不使用他们经过实战考验的解决方案？

几个原因你不想这样做：

您无法查询您的数据
- 与 XML 相比，此数据更自然地适合 JSON，但请忽略这一点 - 当您想要基于属性（或者实际上是元素名称以外的其他内容）进行查询时会发生什么
您失去了强类型属性的好处
- 看起来您只是在创建以集合中的索引为键的子字典...这比使用 XPathNavigator 并遍历选定节点的子节点更容易吗？

我确实看到了编写这样的东西以获得作为初级程序员的经验的价值，但这不属于产品代码——潜在问题太多，实际功能不足。

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

【讨论】：

我很好奇您对“潜在”问题和“足够”的示例有何想法。这些术语对我来说是模棱两可的，例如“足够”有什么资格？潜在的问题是一种直觉，因为您以前见过这样的代码会产生问题？感谢您最初的帖子，并希望您的回复:)
潜在问题包括使用您的课程而产生的任何错误，而您由于尝试添加附加功能而无法通过 Google 搜索。因此，这一切都基于您要添加其他功能的假设。他们会是什么？搜索 DOM？好吧，这意味着您应该使用现有的库。也许弄清楚你是否有一个文本或元素节点？访问属性？这些添加中的任何一个都应该引发“我在我头上”的警报，并提示您使用完整的库......话虽如此，这是一个很好的练习！
我实际上已经解决了所有这些问题。他们很容易解决。你说得对，没有关于这个案例的这些问题的文献，我必须想出问题出现时所需的解决方案。我希望你不要以为总有人比你更聪明而限制自己；）有时没有，不是因为聪明的人无法理解，而是因为他们可能没有经过特定的思路。感谢您的详细说明，我对您的理解有了更好的说明:) 干杯！
而且我会注意不要进入我的头脑。现在这更像是一个实验或者就像你说的一个练习：D

【解决方案2】：

您的数据结构无法处理混合内容，并且不保留元素的顺序。这使得它适用于一些 XML 文档（粗略地说，那些同样可以在 JSON 中处理的文档）并且完全不适合其他文档。

【讨论】：

混合是指标签乱序，即与还是您的意思是混合内容，如“int”、“float”、“string”、“myCustomObject”等？
不，混合内容是指像<p>A <i>right</i> can of worms</p> 这样的文档内容。请记住，XML 中的 M 表示“标记”。
谢谢。这是完美的！

【解决方案3】：

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

但是，我建议使用Linq to XML。代码已经编写和调试，并且具有类似的访问模式。见How to get value of child node from XDocument

【讨论】：

【解决方案4】：

我能想到的缺点是：

在我看来，多个[..] 一个接一个，实在难以理解。您可以很容易地跟踪，尤其是当项目/xml 变得更大时。
创建这样的字典时可能会消耗大量内存。因此，如果您不将整个 xml 加载到这样的结构中，您可能会保留一些空间。可能using 的使用有助于减少这个问题。

另一方面：如果 xml 真的保持那么小，XPath 可能会更慢并且可能有点矫枉过正。

任何一种方式都可以。自己决定什么最合适。

【讨论】：