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

Question

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

每一层都有一个各自的带有接口的程序集，还有一些其他的程序集，如 .Entities、.ViewModels 和通用代码程序集。

持久性- 这包含 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，我可以将Service 层中的IEnumerable 转换为ObjectQuery 以便在那里使用.Include() 吗？

Answer 1

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

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

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

这取决于你是什么IEnumerable<T>真的是。如果是 a 的结果，ToList()则否（因为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向您的查询添加一个- 在存储库方法内部，而不是在服务层中。