NHibernate.3.0.Cookbook第一章第五节Setting up a base entity class

Setting up a base entity class
设置一个实体类的基类

在这节中,我将给你展示怎么样去为我们的实体类设置一个通用的基类。

准备工作

完成前面三节的任务

如何去做

1.在Entity.cs中,为我们的Entity类输入如下代码

public abstract class Entity<TId>
{
public virtual TId Id { get; protected set; }
public override bool Equals(object obj)
{
return Equals(obj as Entity<TId>);
}
private static bool IsTransient(Entity<TId> obj)
{
return obj != null &&
Equals(obj.Id, default(TId));
}
private Type GetUnproxiedType()
{
return GetType();
}
public virtual bool Equals(Entity<TId> other)
{
if (other == null)
return false;
if (ReferenceEquals(this, other))
return true;
if (!IsTransient(this) &&
!IsTransient(other) &&
Equals(Id, other.Id))
{
var otherType = other.GetUnproxiedType();
var thisType = GetUnproxiedType();
return thisType.IsAssignableFrom(otherType) ||
otherType.IsAssignableFrom(thisType);
}
return false;
}
public override int GetHashCode()
{
if (Equals(Id, default(TId)))
return base.GetHashCode();
return Id.GetHashCode();
}
}

2. 在这个文件中,我们添加另一个额外的Entity类,代码如下所示:

public abstract class Entity : Entity<Guid>
{
}

分析原理

  NHibernate需要依赖于Equals方法进行等同性判断。该方法默认定义于System.Object类中,它在引用类型中使用引用相等性判断(即内存地址相同则认为相等),即,x.Equals(y)仅仅在x和y指向相同的对象实例时才是true。这个默认的行为在大多数情况下工作的很好。

  为了支持延迟加载,NHibernate使用代理对象。就像我们之前学习过的,这些代理对象实际上是真正的实体类的子类,为了支持延迟加载,它的每个成员都已经被重写过了。

  这些代理对象,在你的应用程序中这个默认的Equals方法的行为会导致一些隐含和意想不到的bug。一个应用程序对于使用代理对象应该是不知不觉的,是透明的,所以我们期望的情况是,一个代理对象和一个真实的对象如果它们描述的是同一个实体对象,则它们就应该是相等的。如果一个Product对象的ID是8,另一个Product对象的ID也是8,或者有一个代理的Product对象的ID是8,我们应该认为这三个对象是相等的,具有等同性。要做到它们具有等同性,我们必须重写默认的Equals方法,以改变该方法的默认行为(按内存地址判断相等性)。在我们上面的Entity基类中,我们重写了Equals方法,使得该方法基于POID来决定相等性。在Equals(Object obj)方法中,我们简单的调用了其重载方法Equals(Entity<TId> other),尝试把object类型转换为Entity类型,如果转换失败,则会把null值作为参数传递给Equals(Entity<TId> other)方法,如果参数other的值为null,那么这两个对象就不相等。这个有两种情况,第一,x.Equals(null)永远返回false,第二,someEntity.Equals(notAnEntity)也返回false。接下来,我们比较两者的引用地址,很显然,如果两者的变量引用的是同一个实例对象(相同内存地址)则它们必定相等。如果ReferenceEquals(this,other)返回的是true,则我们也返回true。

  再接下来,我们比较Id和默认的Id值,用来判断实体对象是否是临时态,一个处于临时态的对象是一个尚未持久化至数据库中的对象。default(TId)始终返回的是TId的默认值,对于Guid来说,它的默认值是Guid.Empty,对于string和其他所有的引用类型来说,它们的默认值是null,对于数字类型,则默认值为0。如果这个Id属性和它的默认值相等,则该实体对象处于临时态。如果一个或者两个实体处于临时态,则我们认为它们必定是不等的(如果待比较的两个对象中存在一个以上的对象处于临时态,则它们必定不等),需要返回false。

  如果实体对象处于持久态,并且它们都拥有POID,我们就可以通过比较它们的POID值来确定相等性。如果POID不相等,我们就认为待比较的两个实体对象是不相等的(不等同),我们返回false。

  最后,我们还要作最后一次的判断。我们知道至此为止,待比较的对象肯定是处于持久态了,并且它们都有相同的Id值,但是这也不能证明肯定就是相等的。如果一个ActorRole实体和一个Product实体具有相同的POID值,那么如果仅仅是上面的代码的话也会被认为是相等的。我们最后的判断就是要去比较两者的类型,如果其中的一个类型派生了另一个类型,则我们认为它们是相等的。

  假如other参数是一个Product的代理对象,并且描述的是一个book实体,而真正的book实例描述的是同一个对象,那么this.Equals(other)应该返回true,因为它们都描述的是同一个实体对象。然而,不幸的是other.GetType()不是返回Product,而是返回ProductProxy12398712938,而typeof(ProductProxy12398712938).IsAssignableFrom(typeof(Book))的结果会是false,在这种情况下,我们的Equals方法将不可行。正因为如此,我们需要使用other. GetUnproxiedType()方法,它会透过代理层从而返回实际的实体类型,因为typeof(Product).IsAssignableFrom(typeof(Book))返回true,所以我们的Equals实现可以工作的很好。

  因为我们重写了Equals方法,所以我们也必须重写GetHashCode方法,这也是.NET Framework框架规范的要求。如果x.Equals(y),那么x.GetHashCode()和y.GetHashCode()应该返回相同的值,而反过来并不是必须的(如果x.GetHashCode()和y.GetHashCode()返回相同的值,则x.Equals(y)可以返回false),当它们不相等的时候x和y也可以共享一个hash code。在我们的Entity基类中,我们简单地使用了Id的hash code值。

补充知识

更多的关于Equals和GetHashCode的知识,请参阅MSDN文档的相关内容,http://msdn.microsoft.com/en-us/library/system. object.aspx.

补充:

1.     第四节的映射集合中,对ISet集合的处理我们曾经提到过需要重写Equals 和 GetHashCode方法,判断元素是否已经存在于ISet中就需要使用Equals来进行判断。

2.     上面的泛型中TId如果也是一个引用类型的话则也必须重写其Equals 和 GetHashCode方法。

上一篇:docker 安装


下一篇:Java 单例模式:懒加载(延迟加载)和即时加载