IList<KeyValuePair> vs IDictionary 在 WCF 中充当 [DataMember]答案

【问题标题】：IList<KeyValuePair> vs IDictionary to serve as [DataMember] in WCFIList<KeyValuePair> vs IDictionary 在 WCF 中充当 [DataMember]
【发布时间】：2010-11-04 03:09:35
【问题描述】：

我有一个必须使用 WCF 传递的字典数据结构。为此，我使用 get 和 set 方法创建了一个成员属性。我基本上可以实现相同的功能，这个属性是：

IDictionary<keyType, valueType>

或者一个

IList<KeyValuePair<keyType, valueType>>

我看不出选择其中一个的充分理由。我能想到的一个温和原因是：

IDictionary - 阅读代码的人会认为 IDictionary 更有意义，因为数据结构是字典，但就通过 WCF 传递的内容而言，它们都是相同的。

谁能想到选择 IList 的理由？如果没有，我会选择 IDictionary。

【问题讨论】：

标签： c# wcf list dictionary

【解决方案1】：

根据使用而不是实现来设计您的界面。

如果类的使用者需要遍历整个集合，请使用IEnumerable。如果他们应该能够修改结果，并且需要基于索引的访问，则返回 IList。如果他们想要特定的项目，并且有一个有用的键值，请返回 IDictionary。

你的内部代码也是这样写的:)

【讨论】：

消费者是我自己的代码，属性的唯一设置是使数据结构可以被WCF序列化。 getter setter 唯一要做的就是枚举结构的成员，因此 IEnumerable 的替代方法似乎是最简单的可行方法，这总是很好:-)
@David：“该属性的唯一目的是使 WCF 可序列化数据结构”。我不能声称不看代码就完全理解你的场景，但听起来你的设计中可能有一些混合的抽象级别，这导致这样的决策过于复杂。
你能详细说明那条评论吗？
@David：不幸的是，没有可查看的代码，我只能推测 :) 我这么说的原因是，我对代码的印象开始变得模糊。像这样的财产属于哪一类？属性的存在是因为它们在类的上下文中对消费者有意义。如果你有一个属性不能很好地适应一个类的上下文，那么它可能不属于那个类，或者你的类做了太多的事情，或者你的抽象集完全错误。该属性属于哪个类，该类的工作是什么？

【解决方案2】：

这取决于您的消费者。我会迎合最有可能的用例，并使他们的 API 尽可能简单。边缘情况总是可以通过 Values 集合迭代字典。

不要让他们考虑。如果术语字典是他们认为的操作结果，那么带有名称的类型是一个非常有用的东西。

【讨论】：

【解决方案3】：

如果 keyValuePairs 的集合需要唯一键，则可以使用字典。如果同一个键可以出现在多个 keyValuePair 中，请使用 Ilist/ ienumerable。

【讨论】：