带有延迟加载的EF4 POCO。为什么fixup迭代整个数据库?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了带有延迟加载的EF4 POCO。为什么fixup迭代整个数据库?相关的知识,希望对你有一定的参考价值。

这真的是预期的行为吗?我正在使用标准的T4 POCO模板(但是通过http://geekswithblogs.net/danemorgridge/archive/2010/06/28/entity-framework-repository-amp-unit-of-work-t4-template-on.aspx生成的Repository和UnitOfWork虽然问题似乎与POCO修正有关)

如果我做以下事情

        var UOW = new EFUnitOfWork();
        UOW.LazyLoadingEnabled = true;
        UOW.ProxyCreationEnabled = true;
        var horderRepo = RepositoryHelper.GetHORDERRepository(UOW);
        var subrelmRepository = RepositoryHelper.GetSUBRELMRepository(UOW);
        var ho = horderRepo.Where(h=>h.RECORD_NUMBER==1).FirstOrDefault();
        var somerelm = subrelmRepository.Where(r=>r.RECORD_NUMBER==ho.REALM_KEY+1).FirstOrDefault();
        ho.SUBRELM=somerelm;
        UOW.Commit();
        return View(ho);

每次我将ho.SUBRELM更改为新的RELM时,都会调用预期的POCO修正。如果100,000个其他HORDERS(有些人)指向那个relm,那么修正似乎走了很多,永远(或直到内存耗尽 - 以较早者为准)

如果我关闭延迟加载,这不会发生,但我真的希望fixup能够回溯我数据库中的所有关系吗?或者还有其他问题?如果是这样,什么?

答案

这是使用由T4模板生成的具有延迟加载的POCO实体的众所周知的问题。除非您只是将RELM修改为不包含所有包含的HORDERS的导航属性,否则您无法避免它。其他可能性是将T4修改为不使用fixup集合或自己编写POCO。

只是结论 - 这不是EF的错误行为。这是T4模板生成的代码的意外行为。

以上是关于带有延迟加载的EF4 POCO。为什么fixup迭代整个数据库?的主要内容,如果未能解决你的问题,请参考以下文章

MVC3 EF4.1 代码优先延迟加载

IQueryable 实体框架 POCO 映射

EF4 CTP5 POCO 中的软删除、导航属性

EF4 将 DynamicProxies 转换为基础对象

EF4 POCO:快照与 WCF 上的自我跟踪

使用 EF4 的 POCO 模板时“找不到元数据信息”?