Question

这真的是预期的行为吗？我正在使用标准的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能够回溯我数据库中的所有关系吗？或者还有其他问题？如果是这样，是什么？

Answer 1

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

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

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

1 个答案: