带有重复"键"的元组的平面列表vs列表字典C#

时间:2015-03-01 23:34:41

标签: c# linq list dictionary

从配置中读取映射数据时,系统可以使用一种或多种类型(不是.NET类型)

例如:

  • SystemAlpha使用TypeA

  • SystemBeta使用TypeA

  • SystemBeta使用TypeB

这可以存储在List<Tuple<string, string>>类型的平面列表中,作为system, type对,使用LINQ非常容易查询。这里也可以查询哪些类型的系统可以使用哪种类型,这是一个优点。如果每个系统消耗多种类型(即重复的&#34;密钥&#34;),则会有多个条目。缺点是这里的查找速度为O(n)(可以使用O(log(n))的排序列表)

Dictionary<string, List<string>>每个系统只有一个条目,其中包含已消费类型的列表。此处O(1)查找,但缺点是无法轻松查询哪些系统使用特定类型。

映射将足够小(可能),在最坏情况下有O(n)并且有足够的内存(关于字典开销)。

所以我要问的是:

  1. 哪个是最可扩展和可重用的? (也许最终是一个大的映射)
  2. 从代码阅读的角度来看,哪些人以后最容易阅读/使用?
  3. 我是否过度思考这个?
  4. (而MultiValueDictionary尚未完全发布)

2 个答案:

答案 0 :(得分:1)

首先,从某种意义上说,这两种数据结构对您可以存储的数据没有相同的限制,这种比较是不公平的:元组的平面列表允许任意数量的重复“键“,而字典则没有。此限制非常重要:代码的人类读者将从Dictionary<K,V>而不是List<Tuple<K,V>>中读取此含义。

由于将您的意图传达给人类读者是您作为设计师的最重要任务之一,因此使用Dictionary<K,V>是更好的选择。最重要的是,您在帖子中列出的优势也适用:随着您的映射规模的增大,常量查找将变得更加重要。

答案 1 :(得分:1)

我会选择Dictionary<TKey, List<TValue>>。它为以后阅读代码的人提供了更清晰的信息。

如果您确实需要按值查找,则可以使用另一个Dictionary<TKey, List<TValue>>来保持对面方向的参考。将它们包装在一个可以使它们保持同步的类中,可以很容易地确保无论何时发生变化,两个集合都会反映出这些变化。

如果项目数量很少,您可以跳过第二个集合并进行线性查找以确定哪些系统使用特定类型

return dict.SelectMany(x => x.Value.Select(y => new { x.Key, Value = y })
           .Where(x => x.Value == typeToSearch)
           .Select(x => x.Key);