3

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:

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)

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)

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

Should I be taking into consideration which query method I use? Will there be a performance difference? Does the latter use deferred execution? Is one better practice? Or does it not make a difference?

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!

Ross
  • 4,460
  • 2
  • 32
  • 59

1 Answers1

2

There is very big difference.

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.

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.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Thanks for that. Should I avoid navigation properties altogether when used in this context, or would it be equivalent to just make sure I call CreateSourceQuery() on enumerable navigation properties? – Ross Jul 18 '11 at 10:58
  • Once you use `CreateSourceQuery` you are using again IQueryable which is OK. Navigation properties themselves are not for querying. They are for working with related objects. – Ladislav Mrnka Jul 18 '11 at 11:03
  • Is navigation property have any advantages over complied queries for filtering? – ManirajSS Jan 19 '15 at 19:42