Code through the pain Ladislav Mrnka's professional blog about software development


Eager loading is one of core features in Entity Framework. It allows us loading related entities with main entities in a single round trip to the database. This feature should be extended in the future because the current implementation has several limitations:

We can't specify conditions for eager loading

A lot has been written about this limitation including existing highly voted UserVoice suggestion. The current implementation always loads all related records so if we have a main entity which has thousand related entities and we want to get only 10 most recent through eager loading we don't have a direct way to achieve that. We can use a projection to a custom type or an anonymous type to overcome this limitation but that is just a workaround for the missing feature. Eager loading should offer possibility to limit eager loaded data through conditions and to limit number of returned entities - generally strongly typed Include method should support extension methods like Where, OrderBy and Take.

We can't declare eager loading globally

The current implementation demands eager loading to be specified in every query through Include extension method. In most cases the eager loading definition can be wrapped to a separate extension method and reused so the global eager loading would be just a nice to have feature but there are situation where current Include method doesn't work - for example eager loading on inheritance hierarchies is problematic. Entity framework should offer additional ways to define eager loading. I can imagine two such new ways:

  • Global eager loading defined directly in mapping as proposed in already existing UserVoice suggestion
  • Context scope eager loading defined per context instance - similar mechanism was available in LINQ-to-SQL and its DataLoadOptions

Both these implementations would force the query engine to automatically use eager loading of related entities every time the main entity is queried. They should work on inheritance strategies but also for example when the main entity is queried through lazy loading (you will lazy load entity with all relations configured for global eager loading).

We can't specify how should eager loading be executed

At the moment all eagerly loaded data are joined to one result set. This can be absolutely fine in some cases (eager loading of reference property or small collection for few entities) but it can have a significant impact on larger queries with a lot of eagerly loaded data - I described this problem in the answer for the question asked by puretechy on Stack Overflow. We should be able to specify if eager loading should use a join or a separate query to load related data. All details to build the separate query automatically are already present in the main query where we are using eager loading. As a workaround we can specify and execute those separate queries manually but the disadvantage is that Entity Framework doesn't offer any way to batch multiple queries to single round trip to the database. I posted the related suggestion to UserVoice yesterday.

All these features would greatly improve our development experience when using Entity Framework and eager loading. They will also fit to the most required feature on UserVoice: Improve SQL Generation because possibility to control how eager loading is executed and how many data are really loaded is nothing more than improved control over generated SQL.

Posted on April 16, 2012 by Ladislav Mrnka
Filed under: Entity framework

Last week I finished reading of Programming Entity Framework Code First by Julia Lerman and Rowan Miller. I am quite impressed by the content of the book because it contains exactly what the title says and nothing more. It's the definitive guide to using code mapping in Entity Framework but it doesn't cover any additional topics you are not interested in. It keeps the book thin (the real content has 176 pages) so you can finish it within less than one week and use it as reference for your upcoming experience with Entity Framework Code first. The drawback of the book's size and content is that you should not use this book for learning Entity Framework itself. You should first go through some tutorials, trainings or other books before you use this book because this book will not tell you anything about Entity Framework itself. I recommend this book to anybody who has some basic experience with Entity Framework and who is going to use or who is using Entity Framework Code first in his projects. The biggest problem I see in the book is missing index - at least digital versions bought directly on O'Reilly don't  have any. Using technical paper book without index as a reference can be pretty annoying.

Programming EF Code  First Cover

Side note: The book targets Entity Framework 4.2 so small changes in Entity Framework 4.3 and code first migrations are not covered. There is only very small chapter (2 pages) about migrations explaining what will migrations bring to Code First development approach.

Posted on April 1, 2012 by Ladislav Mrnka