在Dictionary中使用对象作为键

Question

将域对象用作词典中的键是一种好习惯吗？

我有一个场景，我使用NHibernate填充我的域对象。

为了执行业务逻辑，我需要查找Dictionary。我可以利用 任

IDictionary<int, ValueFortheObject> 

或

Dictionary<DomainObject, ValueFortheObject>

第二种选择对我来说似乎更好

1. 我可以编写更简单的测试用例，并且可以在测试用例中使用真实域对象，而不是使用Mock<DomainObject>（如果我选择第一个选项），因为Id上的setter是所有域对象都有private。

2. 代码更具可读性，因为Dictionary<Hobbit,List<Adventures>>对我来说比Dictionary<int,List<Adventures>>更具可读性，其中注释表明int是hobbitId，尤其是作为参数传递时

<击> 我的问题是：

<击>

1. 使用第一个选项比第二个选项有什么好处（我可能会盲目地忽略）？

2. 使用第二种方法会出现任何性能问题吗？

更新01：

我的域模型实现了这些，并且在执行操作时不会发生变异。

使用它们作为密钥会有性能问题吗？或者我完全忽略了这一点，性能/内存与正在使用的密钥无关？

更新02：

我的问题是

1. 如果我使用对象作为键而不是原始类型而为什么/如何会不会出现性能或内存问题？

Answer 1

您将遇到的最大问题是，在将关键对象作为关键字执行时，您不得改变它。

当我说“mutate”时，我的意思是你的密钥对象必须实现Equals和GetHashCode才能用作字典的键。在将对象用作键时对对象执行的任何操作都不得更改GetHashCode的值，也不能使Equals使用集合中的任何其他键评估为true。

Answer 2

@ScottChamberlain为您提供了整体问题，但您的使用案例可能会争论。您应该问自己的一些问题是：两个业务对象相等是什么意思？如果它们被用作字典中的键或者我在其他地方比较它们，它们是相同还是不同？如果我更改了一个对象，它的值是否会作为键更改或保持不变？如果您对GetHashCode()和Equals()使用替代，那么计算这些函数的成本是多少？

一般来说，我赞成使用简单类型的键，因为在对象相等方面存在很多误解的空间。如果可读性是您最关心的问题，您可以使用适当的方法创建自定义词典（Dictionary<Key,Value>周围的包装器）。然后，您可以根据对象编写方法，然后在内部使用您想要的任何（适当的）属性。