在 NHibernate 中一切必须是 Virtual 的吗?

原文地址:Must Everything Be Virtual With NHibernate?

 

老赵在博文中 我对NHibernate的感受(2):何必到处都virtual 提到这篇文章,顺便翻译一下。

 

如果你使用过 NHibernate 2.0 或者以后的版本,毫无疑问你将会遇到过几次下面的异常:

NHibernate.InvalidProxyTypeException: The following types may not be used as proxies:
NHibernateExamples.Entities.OrderLine: method get_UnitPrice should be ‘public/protected virtual’ or ‘protected internal virtual’
NHibernateExamples.Entities.OrderLine: method set_UnitPrice should be ‘public/protected virtual’ or ‘protected internal virtual’

 

哎!我们忘了将 OrderList 实体的 UnitPrice 属性设置为 virtual 了。但是,为什么这里必须要设置为 virtual 呢?对于许多 NHibernate 的新手来说,这是一个问题。

对于这个问题的简单答案是:将成员设置为 virtual 是为了延迟加载。

 

更为详细的答案也更加有趣。 对于真正的 ORM 来说,必须具备的一个重要特征是透明的延迟加载。如果你通过 ORM 来获取一个对象,你不会希望它自动的将相关的整个对象图都拉过来(不包括默认情况),你也不会浪费你的代码来检查相关的对象是否已经加载了。应该在需要的时候加载它们,这是 ORM 的责任,理想情况下,如果这些数据还没有加载,在你第一次访问的时候,ORM 来加载需要的数据。

NHibernate 具有这种能力,不需要你继承任何的 NHibernate 基类或者实现任何的接口,或者类似的任何东西。那么,它如何工作呢?好,NHibernate 在需要延迟加载的时候通过你的类的代理来完成。那么,什么是代理?在这里,NHibernate 的代理是一种在初始化应用程序的时候自动生成的类型(这仅仅发生在应用程序启动的时候),一种代理类型对应一种没有明确不使用延迟加载的实体类型,代理类型将会派生自你定义的实体类型,然后注入你可能在这种类型上的操作。

让我们通过一个简单的例子来使这件事更加清楚一些,假设你定义了一个 Order 类,除了其他的成员之外,Order 类有像 Employee 和 Customer 的属性。当你加载 Order 实例的时候,你可能并不希望 Employee 属性已经包含了实际的 Employee 实体,类似地还有 Customer 属性,默认情况下,NHibernate 延迟加载每一个实体,除非明确配置为不延迟。所以,当 NHibernate 初始化的时候,它将会知道需要为 Employee 和 Customer 类型动态生成代理,假设相应的代理类型为 EmployeeProxyType 和 CustomerProxyType,实际的类型不是这些名称,但是不影响我们的讨论,现在,设想你获取了一个 Order 对象实例,你不希望 NHibernate 预先加载 Customer 和 Employee 数据,你没有请求 Customer 或者 Employee 数据,所以,现在还没有这些数据,对不对?但是他们也不应该是 null ,对吗?所以,NHibernate 赋予一个 CustomerProxyType 的实例给 Customer 属性,EmployeeProxyType 的实例给 Employee 属性,然后,初始化这两个属性,使其包含标识信息,这样,你就得到了内存中的订单数据。

你可以安全的使用 Order 实例,甚至可以访问 Employee 和 Customer 属性,但是,一旦你访问没有实际数据的代理成员,包括属性和方法,NHibernate 需要确信 Customer 或者 Employee 的数据从数据库已经获取,NHibernate 怎么处理呢?代理将会重写所有你的属性和方法,当其中任何一个被访问的时候,如果数据还没有实际获取,NHibernate 将会加载数据,然后执行原来属性或者方法的实现逻辑,如果数据已经获取,那么,就会直接调用原来的实现逻辑。

这是基本的面向对象,你定义的实体对于 NHibernate 代理来说是一个基类,这些代理需要扩展你定义实体的行为,来完成上述的功能,NHibernate 需要 override 任何的公共成员来确信在适当的时间触发这些行为。现在,有不少的人不喜欢这种要求。首先,认为这是一个主要的性能花费,访问虚拟成员要比访问非虚拟成员费时,然而,这种性能损失非常小,几乎在任何情况下都可以完全忽略不计。这种花费与真正的性能花费完全不能相比,比如数据库访问的花费。另外一个不喜欢的原因是他们不希望派生类 override 他们的任何成员,在某些情况下,这是一个有力的理由,但是,实际上没有价值。有其他的 ORM 实现不需要你的成员是 virtual 的情况下仍然可以延迟加载,但是,这些 ORM 实现经常要求你或者派生自某个特定的基类,或者实现一个或者多个 ORM 使用的接口,在这两种情况下,我认为 NHibernate 的做法对实体的影响远远低于其他的 ORM ,不过,这只是我的意见。

但是,如果你真的不需要成员是 virtual,而且不使用 NHibernate 的延迟加载,你只需要简单地映射你的实体不使用延迟加载即可,你的映射文件应该如下所示:

 

  < class  name = " OrderLine "  table = " OrderLine "  lazy = " false "   >

 

 

将 lazy 属性设置为 false 将会确信 NHibernate 不会创建你的实例类型的代理类型,你将会得到实际定义的实体类型对象实例,而不会是代理类型的对象实例,这也代表在获得实体对象的时候你将不会得到任何类型的延迟加载。

你可能感兴趣的:(Hibernate)