实体框架-从ObjectContext查询与从导航属性查询 [英] Entity Framework - Querying from ObjectContext vs Querying from Navigation Property

问题描述

我注意到，根据我从实体框架模型提取数据的方式，我会得到不同类型的结果.例如，获取特定部门的雇员列表时:

I've noticed that depending on how I extract data from my Entity Framework model, I get different types of results. For example, when getting the list of employees in a particular department:

如果直接从ObjectContext中提取，则会得到一个IQueryable<Employee>，它实际上是一个System.Data.Objects.ObjectQuery<Employee>:

If I pull directly from ObjectContext, I get an IQueryable<Employee>, which is actually a System.Data.Objects.ObjectQuery<Employee>:

var employees = MyObjectContext.Employees.Where(e => e.DepartmentId == MyDepartment.Id && e.SomeCondtition)

但是，如果我使用MyDepartment的Navigation属性，则会得到一个IEnumerable<Employee>，它实际上是一个System.Linq.WhereEnumerableIterator<Employee>(System.Linq.Enumerable中的私有类):

But if I use the Navigation Property of MyDepartment, I get an IEnumerable<Employee>, which is actually a System.Linq.WhereEnumerableIterator<Employee> (private class in System.Linq.Enumerable):

var employees = MyDeparment.Employees.Where(e => e.SomeCondtition)

在下面的代码中，我在几个LINQ查询(Where，OrderBy，First，Sum等)中大量使用了employees

In the code that follows, I heavily use employees in several LINQ queries (Where, OrderBy, First, Sum, etc.)

我应该考虑使用哪种查询方法?会有性能上的差异吗?后者是否使用延迟执行?有没有更好的做法?还是没有影响?

之所以这样问，是因为自从安装ReShaper 6以来，使用后一种方法时，会得到很多 IEnumerable 警告的可能多重枚举，但是使用直接查询时却没有.我一直在使用后一种方法，这仅仅是因为它写起来更加简洁，而且我想知道这样做是否真的有害！

I ask this because since installing ReShaper 6, I'm getting lots of Possible multiple enumeration of IEnumerable warnings when using the latter method, but none when using direct queries. I've been using the latter method more often, simply because it's much cleaner to write, and I'm wondering if doing so has actually had a detrimental effect!

推荐答案

有很大的不同.

如果使用第一种方法，则具有IQueryable =扩展树，并且仍然可以添加其他表达式，并且只有在执行查询(延迟执行)时，该表达式树才会转换为SQL并在数据库中执行.因此，如果您使用第一个示例并添加.Sum之类的内容，您实际上将在数据库中执行操作，它将仅将单个数字传送回您的应用程序.那就是linq-to-entities.

If you are using the first approach you have IQueryable = exression tree and you can still add other expressions and only when you execute the query (deferred execution) the expression tree will be converted to SQL and executed in the database. So if you use your first example and add .Sum of something you will indeed execute operation in the database and it will transfer only single number back to your application. That is linq-to-entities.

第二个示例在内存收集中使用.导航属性不代表IQueryable(表达式树).所有linq命令都被视为linq-to-objects =必须首先将所有表示导航属性中相关数据的记录从数据库加载到您的应用程序，并且所有操作都在应用程序服务器的内存中完成.您可以(通过使用Include)，显式(通过使用Load)或延迟(如果启用了延迟加载，则在首次访问该属性时会自动完成)来快速加载导航属性.因此，如果您想获得一定的总和，则此方案要求您从数据库加载所有数据，然后在本地执行该操作.

The second example uses in memory collection. Navigation property doesn't represent IQueryable (expression tree). All linq commands are treated as linq-to-objects = all records representing related data in navigation property must be first loaded from database to your application and all operations are done in memory of your application server. You can load navigation property eagerly (by using Include), explicitly (by using Load) or lazily (it is just done automatically when you access the property for the first time if lazy loading is enabled). So if you want to have sum of something this scenario requires you to load all data from database and then execute the operation locally.

这篇关于实体框架-从ObjectContext查询与从导航属性查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！