EF4：为什么在启用延迟加载时必须启用代理创建？

Question

我的项目结构如下：.Persistence - > .Repo - > .Services - > .Controllers - > MVC3 App。

每个层都有一个带接口的相应程序集，还有一些其他程序集，如.Entities，.ViewModels和公共代码程序集。

持久性 - 它包含EF4 datacontext（代码优先）和对EF4.3的引用。 有一个工厂用于创建名为GetContext（）的Context，这个工厂实现了IDisposable。 这不是一个单身因素我认为这就是温莎会用LifestyleSingleton（）为我做的事情。
回购 - 这包含实现存储库和规范模式的存储库（ http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/ ）。

其他层次不言自明......

问题：
1.为什么在启用延迟加载时必须启用代理创建？
2.如果我想设置lazyloading = false，我可以将我的IEnumerable在Service层中转换为ObjectQuery以便在那里使用.Include（）吗？

Answer 1

为什么在启用延迟加载时必须启用代理创建？

因为POCO的延迟加载依赖于代理创建。 没有代理延迟加载不起作用。 因此，组合ProxyCreationEnabled = false和ProxyCreationEnabled = false LazyLoadingEnabled = true是没有意义的。 如果您想使用更改跟踪代理但不想使用延迟加载，则反向组合是有意义的。

如果我想设置lazyloading = false，我可以将我的IEnumerable在Service层中转换为ObjectQuery以便在那里使用.Include（）吗？

这取决于你的IEnumerable<T>究竟是什么 。 如果它是ToList()的结果则为no（因为List<T>是IEnumerable<T>的实现，但不是IQueryable<T> 。）。 如果你只是将一个IQueryable<T>作为IEnumerable<T>你可能会转换为IQueryable<T> 。 （在EF 4.3中，您将使用IQueryable<T>或DbQuery<T>而不是ObjectQuery<T> 。）

但是，我需要这样的演员表明你的架构出了问题。 使用Include是对查询的修改。 如果允许服务层修改查询，则存储库应返回IQueryable<T> - 此类型用于构建和修改查询。

如果您的存储库不应返回IQueryable<T> ，则必须将表达式或规范传递到存储库方法，该方法用于向查询添加Include - 在存储库方法内部，而不是在服务层中。