1

很多消息来源都在谈论这个问题，但我不太了解这个概念。IDictionary 是通用的，它的类型安全等。

当我深入研究 EntityFrameworkv5 时，我看到一个在 LogEntry 类中声明如下的属性。

private IDictionary<string, object> extendedProperties;

问题是为什么他们更喜欢 IDictionary 而不是 Hashtable，因此 Hashtable 也将键作为字符串和对象。唯一的原因是通过选择 IDictionary 使属性多态？

提前致谢。

4

4 回答 4

3

如今，使用Hashtable. Dictionary<>在大多数方面都比它好。如果不是，您通常可以找到另一个比任何一个都更好地满足您的目的的强类型集合。

  • 类型安全。
  • 没有装箱和拆箱的严重开销。
  • 实现IDictionary<>，与 .NET 和 3rd 方代码非常兼容。
  • Hashtable在许多方面表现得更好。见链接： 链接#1，链接#2。

如果您要问为什么键入属性IDictionary<>而不是Dictionary<>，这是有几个原因的。

  • 通常认为最好的做法是尽可能频繁地使用接口，而不是常规类型，尤其是在框架中。
  • 可以相当容易地更改接口的实现，但是很难更改具体类的性质而不引起与相关代码的兼容性问题。
  • 使用接口，您可以利用Covariance 和 Contravariance。
  • IDictionary<>与具体类相比，外部代码更可能使用更通用的接口Dictionary<>。因此，使用IDictionary<>它可以让其他开发人员更好地与该属性进行交互。
  • 可能还有很多。这些只是我的想法。
于 2012-06-09T19:12:11.517 回答
1

是的，如果他们将扩展属性定义为返回哈希表，那么他们将一直坚持下去，除非他们想破坏所有使用扩展属性的代码。

返回一个接口的重点是，只要它继续这样做，方法是如何实现的并不重要。

“唯一的原因是使属性多态”没有抓住重点，你不应该这样做的理由应该很少。如果您可以返回一个接口，请务必返回一个接口，大多数情况下这是好的设计。

于 2012-06-09T18:17:33.137 回答
1

因此，这里的大多数答案都是关于将 Dictionary 与 Hashtable 进行比较的一般目的，而不是他们选择该特定实现的原因。

在那个特定的实现中，你是对的，它使用对象作为返回类型，所以字典的强类型优势不可用。

IMO 归结为 New vs Old、ArrayList、Hashtable 等是较旧的技术，并且通常在很大程度上不受欢迎，因为它们没有许多功能（在其他答案中描述）。尽管在这种特殊情况下没有使用这些功能，但切换回旧技术并没有很大的好处，它为个人发展提供了一个更好的例子。

所以这更像是“这就是我们现在做的方式”的问题

于 2012-06-11T14:02:22.353 回答
0

HashTable 是弱类型的，只能返回 Object。Dictionary<> 对于您存储在其中的任何类型都是强类型的。

于 2012-06-09T18:29:20.457 回答