NHibernate通过session.Load()创建代理，但不通过Linq或Criteria API创建代理

编程入门行业动态更新时间:2024-10-09 15:16:58

本文介绍了NHibernate通过session.Load()创建代理，但不通过Linq或Criteria API创建代理的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！问题描述

我当前的项目有一个奇怪的问题.延迟加载查询不起作用.当我查询列表时，nhibernate分别获取所有关联.

I have an odd problem in my current project. Lazy loading for queries does not work. When I query a list, nhibernate fetches all associations separately.

我提取了其中的一小部分，并将其放入单独的溶液中.基本上，我现在得到的是一个Account-Table和一个AccountSync-Table.两者都有一个ID和一个URL，而ID只是一个db-guid.

I extracted small parts of it and put it into a separate solution. Basically what I've got now, is a Account-Table and a AccountSync-Table. Both have an ID and a URL, while the ID is just a db-guid.

我的课程是:

public class HippoAccount { public virtual Guid Id { get; set; } public virtual string Url { get; set; } public virtual HippoAccountSync Sync { get; set; } } public class HippoAccountSync { public virtual Guid Id { get; set; } public virtual string Url { get; set; } public virtual HippoAccount Account { get; set; } }

当我现在通过它的GUID加载对象时:

When I now load a object via it's guid:

var account = session.Load<HippoAccount>(accountId); Console.WriteLine(NHibernateUtil.IsPropertyInitialized(account, "Sync"))

...它返回false，并且帐户本身是代理.

... it returns false and account itself is a proxy.

但是在通过标准API加载列表时:

But when loading a list via the criteria API:

var account = (HippoAccount)session .CreateCriteria(typeof (HippoAccount)) .Add(Restrictions.Eq("Id", accountId)) .List()[0];

...属性Sync被初始化(触发第二个选择查询)，并且返回的对象不是代理.

... the property Sync gets initialized (firing a second select query), and the returned object is not a proxy.

这是默认行为吗?我怎么了?

Is that default behaviour? What am I getting wrong?

映射为:

推荐答案

经过更多研究后，我找到了答案.答案是，因为有很多事情可以阻止NHibernate中的延迟加载.

After quite some more research, I found the answers. Answers, because there are many things that can prevent lazy loading in NHibernate.

查询与会话加载.:通过session.Load()获取项目时，您将获得一个代理.但是，只要您访问 any 属性(假设是Url)，就会提取该对象，包括所有不支持延迟加载的关联.

Query vs. session.Load: When fetching an item via session.Load() you get a proxy. But as soon as you access any property, lets say the Url, the object is fetched including all it's associations that doesn't support lazy loading.

属性参考:延迟加载仅适用于对象ID.通过目标实体中的其他列解析属性关联后，NH会急切地获取它. 这不是不可能，只是没有实现:错误

property-ref: Lazy loading only works over a objects id. When an property-association is resolved via a different column in the target entity, NH fetches it eagerly. Not that this wouldn't be possible, it's just not implemented: Bug

未找到="ignore" 允许无效外键，也就是说，如果未找到引用的实体，NH将使用null初始化该属性. NH不会拦截延迟加载的属性访问，而是分配一个对象代理.使用not-found="ignore"时，无法确定是否应将该属性设置为null或给定的(可能是无效的)外键的代理. 可以通过拦截属性访问来解决.

not-found="ignore" allows invalid foreign keys, that is, if the referenced entity isn't found NH will init the property with null. NH doesn't intercept the property-access for lazy loading, but instead assignes a object proxy. With not-found="ignore" it can't decide if the property should be set to null or a proxy for the given, possibly invalid, foreign key. This could possibly be solved by intercepting the property access.

在禁用not-found="ignore"和property-ref时，架构导出将生成强制实施循环引用的约束.不好！正确的映射将是受约束的一对一关系，其中HippoAccountSync的密钥必须具有生成器foreign.

When disabling not-found="ignore" and property-ref the schema export would generate constraints that enforce a circular reference. Not good! The correct mapping would then be a constrained one-to-one relationship, where the key for HippoAccountSync must have a generator foreign.

资源