NHibernate: Reasons for overriding Equals and GetHashCode

Question

Are there any reasons why Equals or GetHashCode should be overriden in entities when using NHibernate? And in which scenarios are these reasons valid?

Some reasons that can be found on web:

• Support for lazy loading. Comparing proxy objects via default Equals method can lead to unexpected bugs. But this should be resolved by identity map (and it really is in many cases), should not it? When working with entities from single session everything should work fine even without overriding Equals/GetHashCode. Are there any cases when the identity map does not play well it‘s role?
• It is important for NHibernate collections. Are there any cases when default implementation of GetHashCode is not sufficient (not including Equals related issues)?
• Mixing entities from several sessions and detached entities. Is it good idea to do so?

Any other reasons?

Answer 1

As you mention in your question, identity of an entity instance is the main requirement for overriding Equals & GetHashCode. It is a best practice in NHibernate to use numeric key values (short, int, or long as appropriate) because it simplifies mapping an instance to a database row. In the database world, this numeric value becomes the primary key column value. If a table has what is called a natural key (where several columns together uniquely identify a row) then a single numeric value can become a surrogate primary key for this combination of values.

If you determine that you don't want to use or are prevented from using a single numeric primary key then you'll need to map the identity using the NHibernate CompositeKey functionality. In this case, you absolutely need to implement custom GetHashCode & Equals overrides so the column value checking logic for that table can determine identity. Here is a good article on overriding the GetHashCode and Equals method. You should also override the equal operator to be complete for all usages.

From the comment: In which cases is default implementation of Equals (and GetHashCode) insufficient?

The default implementation is not good enough for NHibernate because it is based on the Object.Equals implementation. This method determines equality for reference types as reference equality. In other words, are these two objects pointing to the same memory location? For NHibernate, the equality should be based on the value(s) of the identity mapping.

If you don't, you will most likely run into comparing a proxy of an entity with the real entity and it will be miserable to debug. For example:

public class Blog : EntityBase<Blog>
{
    public virtual string Name { get; set; }

    // This would be configured to lazy-load.
    public virtual IList<Post> Posts { get; protected set; }

    public Blog()
    {
        Posts = new List<Post>();
    }

    public virtual Post AddPost(string title, string body)
    {
        var post = new Post() { Title = title, Body = body, Blog = this };
        Posts.Add(post);
        return post;
    }
}

public class Post : EntityBase<Post>
{
    public virtual string Title { get; set; }
    public virtual string Body { get; set; }
    public virtual Blog Blog { get; set; }

    public virtual bool Remove()
    {
        return Blog.Posts.Remove(this);
    }
}

void Main(string[] args)
{
    var post = session.Load<Post>(postId);

    // If we didn't override Equals, the comparisons for
    // "Blog.Posts.Remove(this)" would all fail because of reference equality. 
    // We'd end up be comparing "this" typeof(Post) with a collection of
    // typeof(PostProxy)!
    post.Remove();

    // If we *didn't* override Equals and *just* did 
    // "post.Blog.Posts.Remove(post)", it'd work because we'd be comparing 
    // typeof(PostProxy) with a collection of typeof(PostProxy) (reference 
    // equality would pass!).
}

Here is an example base class if you're using int as your Id (which could also be abstracted to any identity type):

public abstract class EntityBase<T>
    where T : EntityBase<T>
{
    public virtual int Id { get; protected set; }

    protected bool IsTransient { get { return Id == 0; } }

    public override bool Equals(object obj)
    {
        return EntityEquals(obj as EntityBase<T>);
    }

    protected bool EntityEquals(EntityBase<T> other)
    {
        if (other == null)
        {
            return false;
        }
        // One entity is transient and the other is not.
        else if (IsTransient ^ other.IsTransient)
        {
            return false;
        }
        // Both entities are not saved.
        else if (IsTransient && other.IsTransient)
        {
            return ReferenceEquals(this, other);
        }
        else
        {
            // Compare transient instances.
            return Id == other.Id;
        }
    }

    // The hash code is cached because a requirement of a hash code is that
    // it does not change once calculated. For example, if this entity was
    // added to a hashed collection when transient and then saved, we need
    // the same hash code or else it could get lost because it would no 
    // longer live in the same bin.
    private int? cachedHashCode;

    public override int GetHashCode()
    {
        if (cachedHashCode.HasValue) return cachedHashCode.Value;

        cachedHashCode = IsTransient ? base.GetHashCode() : Id.GetHashCode();
        return cachedHashCode.Value;
    }

    // Maintain equality operator semantics for entities.
    public static bool operator ==(EntityBase<T> x, EntityBase<T> y)
    {
        // By default, == and Equals compares references. In order to 
        // maintain these semantics with entities, we need to compare by 
        // identity value. The Equals(x, y) override is used to guard 
        // against null values; it then calls EntityEquals().
        return Object.Equals(x, y);
    }

    // Maintain inequality operator semantics for entities. 
    public static bool operator !=(EntityBase<T> x, EntityBase<T> y)
    {
        return !(x == y);
    }
}