基于数据库行唯一ID实现POCO的GetHashCode与Equals方法是否安全？

我有一个对应数据库行的POCO类，能够获取该行的唯一ID，想请教各位：借助这个唯一ID来实现GetHashCode和Equals方法是否安全？

以下是我的实现代码：

public class Project {
    public string ID { get; }
    public string Name { get; set; }
    public override bool Equals(object obj) {
        var pr = obj as Project;
        if (pr == null) return false;
        if (pr.ID == null) throw new InvalidOperationException("Attempt to .Equals an entity with null ID");
        return pr.ID == ID;
    }
    public override int GetHashCode() {
        if (ID == null) throw new InvalidOperationException("Attempt to .GetHashCode on an entity with null ID");
        return ID.GetHashCode();
    }
}

我认为这种实现是可行的，理由如下：

• ID是不可变的；
• 我已经处理了ID为null的情况。

想听听大家对这个方案的看法？

我的解答 #

这个方案整体是合理且安全的，但有几个细节需要结合你的实际场景来考量：

• 核心逻辑的合理性
  对于对应数据库行的实体类来说，我们通常追求的是「标识相等」——即只要是对应同一数据库行的实例，就视为相等，而不是看属性是否完全一致。你的实现正好贴合这个语义，唯一ID作为数据库行的唯一标识，用来判断相等性是完全符合业务逻辑的。

• 不可变ID的关键作用
  你把ID设为get-only的不可变属性，这是非常正确的选择！因为GetHashCode的结果要求在对象的生命周期内保持稳定，如果ID可以被修改，那么同一个对象在修改ID前后的哈希值会变化，导致它在Dictionary、HashSet这类哈希集合中「丢失」，无法被正常查找或移除。你的实现避免了这个致命问题。

• 需要注意的场景细节

  1. 未持久化实例的处理
     如果你的Project类会存在未被持久化到数据库的实例（也就是还没有分配ID的新对象），那么当前抛出异常的逻辑会导致这些实例无法使用Equals和GetHashCode——比如把它们加入哈希集合时直接报错。这种情况下，你可以补充逻辑：比如新增一个IsTransient属性，对于未持久化的实例，用引用相等（object.ReferenceEquals(this, obj)）来判断相等性，哈希值也基于引用生成。
  2. 子类继承的问题
     当前的Equals实现只判断了对象是否能转为Project，如果有子类继承Project，那么子类实例和父类实例如果ID相同，会被视为相等，但实际上它们是不同类型的对象，这可能不符合预期。可以加上类型判断：return pr.ID == ID && GetType() == pr.GetType();，确保只有同类型的实例才会通过ID判断相等。
  3. 哈希冲突的风险
     虽然string.GetHashCode已经做了优化，但理论上存在哈希冲突的可能——不同的ID字符串生成相同的哈希值。不过对于数据库的唯一ID（比如GUID、自增ID转的字符串）来说，冲突概率极低，几乎可以忽略不计，这个风险是可接受的。
  4. 异常抛出的合理性
     在Equals和GetHashCode中抛出异常，需要确保调用这些方法的场景能提前规避这种情况——比如不要把未分配ID的实例传入依赖相等性判断的方法或集合中。如果无法避免，也可以考虑返回一个固定的哈希值（比如0）并在Equals中处理null ID的情况，但这样可能会影响哈希集合的性能。

总结 #

如果你的Project实例都是已经持久化到数据库、拥有有效ID的，那么当前的实现是安全且符合业务逻辑的；如果存在未持久化的实例或子类继承的场景，只需要针对性地补充逻辑即可。

内容的提问来源于stack exchange，提问作者Arthur Attout