NHibernate 警告缩小代理到 - 此操作中断 ==

Question

我有一个关于 NHibernate 中代理的问题。我的日志文件中有很多日志，例如：Narrowing proxy to - this operation breaks == 网上还有其他一些问题和不同的答案：

Stackoverflow NHibernate narrowing proxy warning 这是否重要取决于您愿意接受的风险程度。由于您的代码和数据库之间总是存在脱节，因此您不能始终确保铸造将起作用。 这将导致可能难以诊断的错误，如果不更改数据库或代码可能无法解决。

hibernate 的另一个帖子：

Narrowing problem 别担心他的警告，只需将以下内容放入您的日志文件中，您应该就不会再看到它了...

为什么会这样？ 假设您有一个与地址具有多对一关联的产品。两者都是实体，并且 Address 有一个 ShippingAddress 子类。

让我们 Session.get(..) 从具有 ShippingAddress 作为关联的数据库中获取产品。因为多对一是惰性的，它会返回一个地址代理。请注意，这是一个 Address 代理而不是 ShippingAddress 代理，因为代理将始终与 Product 中提到的类型匹配（有关详细信息，请参阅 hibernate 手册）。

这个代理被 Hibernate 存储在他的代理缓存中。 现在我们 Session.get(...) 从数据库中获取相同的 ShippingAddress，该地址与我们使用的从数据库中获取的产品相关联。 现在 Hibernate 将看到它已经包含此 ShippingAddress 的代理并将返回它。但是，它会注意到类型不同，因此必须发生“向下转换”。因为“代理”无法执行后一种操作，所以它会创建一个新的并返回它......

如您所见，没什么好担心的。 您可以考虑将地址设为值类型... 在我的情况下，这是没有选择的。

最后一个

ProxyWarnLog Removed in Hibernate 4?

这是来自 NHibernate 的代码：StatefulPersistenceContext.cs -> NarrowProxy(..)

那么，这是否有问题？我总是在我的程序中使用分离的对象。 我希望有一个人可以帮助我。 非常感谢。

Answer 1

如果您使用 == 运算符比较实体并确定它们是否相同，这可能会很麻烦。

当您将实体添加到映射为set 的集合时，这确实会发生类似的情况（但确实是Equals）。如果集合碰巧已经包含实体但通过另一种代理类型实例化，add 可能无法遵守其约定，它可能会再次添加实体，然后 set 将包含两个同一实体的出现次数。

这是可能，而不是将，因为您可以通过覆盖Equals（和GetHashcode，因为必须返回相同的对象哈希码）在您的实体上，以便通过它们的主键和实体类型比较它们。对于set，这就足够了（因为它不使用== 运算符，而是使用Equals 方法，如果您的类型实现它，则优先使用IEquatable<T> 中的那个）。

对于==，您需要在您的类上定义== 和!= 运算符以使用您的Equals 实现。

阅读here 或here 了解更多信息。请注意，他们的示例实现只是示例，不适合使用继承的域模型。阅读here 了解处理继承的最重要示例。 （但它不处理瞬态实体：最好在natural ids 上附加一个最终测试（如果有的话），而不是在两者都被认为是瞬态但不是同一个参考时产生假。）这个blog 提供了一个基础重新定义 == 的类（在此 Stack Overflow question 中找到）。

使用分离的实体会增加这种风险。如果您尚未在实体上覆盖这两个方法，那么不管这个警告如何，这样做会更安全。