深层嵌套字典是反模式吗?
我有一个可以很容易地使用三层嵌套字典来表示的结构,就像这样
private static Dictionary<string, Dictionary<string, Dictionary<string,string>>> PrerenderedTemplates;
结构可能会使用这样的地方
PrerenderedTemplates[instanceID][templategroup][templatepart]
现在,我意识到这段代码很难阅读,因为从定义语句来看,你无法说出它的用途。我真正看到的将其更改为 Dictionary
的唯一优点是可读性。将每个嵌套转换为它自己的类(例如class PrerenderedTemplate{} class TemplateGroup{} class TemplatePart{}
)会添加更多行代码,但计算优势很小(如果有的话)。据我所知。
- 那么,我的方法“可以”还是我应该加倍努力并创建单独的类?
- 是否可以在文档/评论中介绍嵌套
Dictionary
的工作原理 - 是否有处理此类嵌套的最佳实践?
- 请记住,这是一个私有成员,对于使用该类的人来说不需要很简单。
更新
因此,受到 Reza 的启发,但无法使用元组,我决定创建自己的密钥生成器并实现他的模式,如下所示:
private Dictionary<string, string> PrerenderedTemplates;
private string GetPrerenderedTemplateKey(string InstanceId, string FeatureId, string OptionId)
{
return new StringBuilder(instanceId)
.Append(FormatTools.LIST_ENTRY_DELIMITER)
.Append(templategroup)
.Append(FormatTools.LIST_ENTRY_DELIMITER)
.Append(templatepart).ToString();
}
其中 FormatTools.LIST_ENTRY_DELIMITER
是 Unicode Private使用字符0xe04d
。
I have a structure that can be very easily represented using a three-deep nested dictionary, like so
private static Dictionary<string, Dictionary<string, Dictionary<string,string>>> PrerenderedTemplates;
Where the structure might be used something like this
PrerenderedTemplates[instanceID][templategroup][templatepart]
Now, I realise that this code is hard to read, because from looking at the definition statement, you can't tell what it's being used for. The only advantage I can really see in changing it to Dictionary<string, PrerenderedTemplate>
is readability. Converting each nesting into its own class (e.g class PrerenderedTemplate{} class TemplateGroup{} class TemplatePart{}
) would add many more lines of code for little (if any) computational advantage. As far as I can see.
- So, is my approach "ok" or should I go the extra mile and create seperate classes?
- Is it okay to cover how the nested
Dictionary
works in the documentation/comments - Is there a best practice for handling this sort of nesting?
- Bear in mind, this is a private member, it doesn't need to be straightforward for people using the class.
Update
So, inspired by Reza, but unable to use Tuples, I decided to create my own key generator and implement his pattern like this:
private Dictionary<string, string> PrerenderedTemplates;
private string GetPrerenderedTemplateKey(string InstanceId, string FeatureId, string OptionId)
{
return new StringBuilder(instanceId)
.Append(FormatTools.LIST_ENTRY_DELIMITER)
.Append(templategroup)
.Append(FormatTools.LIST_ENTRY_DELIMITER)
.Append(templatepart).ToString();
}
Where FormatTools.LIST_ENTRY_DELIMITER
is the Unicode Private Use Character 0xe04d
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我提供另一种选择:
访问字典:
C# 7中引入的值元组最引人注目:
访问字典:
I offer another choice:
Access to dictionary:
Value Tuples introduced in C# 7 is most eye-catching:
Access to dictionary:
我会创建一个自定义词典。 如果您认为
连接字符串不够安全,因为键可能包含分隔符,那么请使用您自己的键类型或
Touple
作为键。由于此实现细节隐藏在您的自定义字典中,因此您可以随时更改它。你可以像这样使用字典
I would create a custom dictionary. Something like this
If you think, concatenating the strings is not safe enough, because the keys could contain the separators, then use your own key type or a
Touple<string,string,string>
as key. Since this implementation detail is hidden inside your custom dictionary, you can change it at any time.You can use the dictionary like this
我想提供一种替代方法,使用 SortedDictionary 和自定义比较器:
像这样使用:
RezaArab 的答案适合目的,但我个人不喜欢 Tuples它们模糊的属性和冗长的语法的基础。
如果任何需求发生变化,带有比较器的自定义类可以提供更高的清晰度和灵活性。
I would like to offer an alternative approach, using a SortedDictionary and a custom comparer:
Is used like so:
RezaArab's answer is fit for purpose but personally I dislike Tuples on the basis of their ambiguous properties and verbose syntax.
A custom class with comparer offers more clarity and also flexibility, should any requirements change.