在我的代码中使用许多字典中的字典

Dictionary<Guid, List<string>>()
Dictionary<Guid, Dictionary<Guid, List<string>>>()

你会遇到这样的限制吗?你的程序很难修改/调试吗?如果是，重构。否则，利润:你是一个务实的程序员，

话虽如此，我仍能看到立即改进的空间:

IDictionary<Guid, List<string>> x;
IDictionary<Guid, IDictionary<Guid, List<string>> y = new Dictionary<Guid, IDictionary<Guid, List<string>>();

我会说是的，为它专门创建一个类。然后，您可以根据您的使用情况添加/不实现方法，而不是绕过您在Dictionary中发现的任何限制。

听起来你想要一个树形结构

至少，将你的"臭"数据结构包装在一个类中，这样你就可以通过提供一个干净的API来封装它的实现来查询/修改数据，而不需要任何客户端代码知道任何关于存储细节的信息。

那么在将来的任何时候，您都可以自由地更改数据结构的实现。如果你现在不这样做，当你有10倍或100倍的客户端代码时，你可能会后悔，重构它太昂贵/痛苦了。

你可能会发现，只要你保持它整洁的封装，它就能工作，你觉得它很臭的事实是无关紧要的——只要代码做了它需要做的事情，并且是可维护的，就没有必要在它上面投入更多的时间。(我并不提倡保留肮脏的代码，但我们必须平衡商业现实和我们实现理论完美的愿望——如果代码可以工作并且没有引起任何问题，那么改进或重构它可能并不总是值得你花时间的。)相反，您可能会发现，仅仅通过将其封装在一个类中并将脏实现与其客户端隔离来消除风险，现在就足够了)

因为Dictionary类型是引用类型，所以这里的情况并不坏，但是为了代码清晰起见，考虑定义一个新的类型，从Dictionary<Guid,List<string>>派生，以便缩短编写的代码并使其易于阅读。这个类应该是这样的:

internal class MyWrapper : Dictionary<Guid, List<string>>
{
}

或者如果对你来说保持IDictionary很重要，那么通过将Dictionary<Guid, List<string>>实例包装到实现IDictionary<Guid, List<string>>的类中并将所有方法委托给包装的字典，继续进行复合设计。

。. NET 4.0引入了Tuple，这是一种更容易被滥用的数据结构，它一开始看起来很好，但后来带来了很多痛苦，应该明智地使用。

Dictionary在某种程度上没有那么邪恶，因为它服务于快速元素访问，而不仅仅是作为粘合剂而不是创建类。我相信你对字典的使用是没有问题的如果这些字典是在一个方法中局部使用的用于一些计算或其他东西，但是当你开始将它们作为参数传递时就不那么清楚了。如果是这种情况，我认为您需要为它创建一个类。