1

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

我有一个场景，我使用NHibernate.

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

IDictionary<int, ValueFortheObject>

或者

Dictionary<DomainObject, ValueFortheObject>

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

  1. 我可以编写更简单的测试用例，也可以在测试用例中使用真实的域对象，而不是使用Mock<DomainObject>（如果我选择第一个选项），因为 setter on the Idis privateon all domain objects。

  2. 与建议 int 的注释Dictionary<Hobbit,List<Adventures>>相比，代码更具可读性，尤其是在作为参数传递时Dictionary<int,List<Adventures>>hobbitId

我的问题是：

  1. 使用第一个选项比第二个选项有什么优势（我可能会盲目地错过）？

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

更新01：

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

使用它们作为键会有性能问题吗？还是我完全错过了这里的重点，性能/内存与使用的键无关？

更新02：

我的问题是

  1. 如果我使用 Objects 作为键而不是原始类型和WHY / HOW，性能或内存是否会出现任何问题？
4

2 回答 2

4

您将遇到的最大问题是您不能在您的键对象作为键执行滚动时对其进行变异。

当我说“变异”时，我的意思是您的键对象必须实现Equals并GetHashCode用作字典的键。当对象用作键时，您对对象所做的任何事情都不得更改集合中任何其他键的值，GetHashCode也不得导致评估为真。Equals

于 2012-12-15T18:36:28.757 回答
1

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

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

于 2012-12-15T18:48:41.420 回答