EF4:为什么在启用延迟加载的情况下必须启用代理创建
本文关键字：启用 代理 创建 情况下 延迟加载 为什么 EF4 | 更新日期: 2023-09-27 18:26:04
我有一个项目结构如下：.Persistence->.Repo->.Services->.Controllers->MVC3应用程序。
每个层都有一个带接口的相应程序集，还有一些其他程序集，如.Entities、.ViewModels和公共代码程序集。
Persistence-它保存EF4数据上下文（代码优先）和对EF4.3的引用。有一个用于创建上下文的工厂，名为GetContext（），该工厂实现IDisposable。这不是一个单身，因为我想这就是windsor用LifestyleSingleton（）为我做的
Repo-它包含实现存储库和规范模式的存储库(http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/)。
其他层次是不言自明的。。。
问题：
1.为什么在启用延迟加载的情况下必须启用代理创建
2.如果我想设置lazyloading=false，我可以将服务层中的IEnumerable强制转换为ObjectQuery以便在那里使用.Include（）吗？
为什么在启用延迟加载时必须启用代理创建？
因为POCO的延迟加载依赖于代理创建。没有代理，延迟加载是不起作用的。因此CCD_ 1和CCD_。如果您想使用更改跟踪代理，但又不想使用延迟加载，那么反向组合是有意义的。
如果我想设置lazyloading=false，我可以将服务层中的IEnumerable强制转换为ObjectQuery以便在那里使用.Include（）吗？
这取决于您的IEnumerable<T>真正是什么。如果它是ToList()的结果，则为no（因为List<T>是IEnumerable<T>的实现，而不是IQueryable<T>的实现。）。如果只将IQueryable<T>返回为IEnumerable<T>，则可能可以强制转换为ProxyCreationEnabled = false0。（在EF 4.3中，您将使用IQueryable<T>或DbQuery<T>，而不是ObjectQuery<T>。）
但是，如果需要这样的演员阵容，则表明您的体系结构中出现了问题。使用Include是对查询的修改。如果您的服务层被允许修改查询，那么您的存储库应该返回IQueryable<T>——这种类型是用于构建和修改查询的。
如果您的存储库不应该返回IQueryable<T>，则必须将表达式或规范传递到用于向查询添加Include的存储库方法中——在存储库方法内部，而不是在服务层中。