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

【问题标题】：EF4 POCO with Lazy Loading. Why does fixup iterate entire database?具有延迟加载的 EF4 POCO。为什么 fixup 会迭代整个数据库？
【发布时间】：2019-03-06 17:22:35
【问题描述】：

这真的是预期的行为吗？我正在使用标准的 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 修复程序。如果该 relm 被 100,000 个其他 HORDERS（其中一些是）指向，那么修复似乎会影响他们中的很多人，永远（或直到内存耗尽——以较早者为准）

如果我关闭延迟加载，这不会发生，但我真的应该期望修复程序回溯数据库中的所有关系吗？还是有其他问题？如果有，是什么？

【问题讨论】：

标签： c# entity-framework entity-framework-4 poco

【解决方案1】：

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

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

【讨论】：

谢谢拉迪斯拉夫。 “意外行为”（说得好）是一个主要问题 - 现在我有大量数据（主表中有 10 万条记录）问题无处不在：上面的代码只是为了证明一点。短期选择是避免 POCO，或修改 T4。我想我现在可能会回到默认代码生成。
@Andiih：我不喜欢那些修正。它们在某些情况下很有用，但大多数时候很烦人。例如代码优先不使用它们，一切仍然有效。