I think the proper way to start this post is to ask How do you do eager loading with Entity Framework? And the basic native simple answer is by using ObjectQuery<T>.Include(string) method. No matter what you tried to do, you’ll end up using this way.

So there was ideas about how enhance the eager loading in our Entity Framework base applications. You can read about some of these ideas:

• Entity Framework Include with Func & Entity Framework Include with Func next by Matthieu MEZIL
• Typed Eager Loading Using Entity Framework (& What is Eager Loading vs Deferred Loading) by Meligy
• Fetching strategy posts by Simon Segal:
• Fetching Strategies for the Entity Framework - a waste of time for now?
• Entity Framework Repository, Specifications and Fetching Strategies
• The Entity Framework and a unified Lazy and Eager loading framework
• Entity Framework, Repositories, Specifications and Fetching Strategies Part 9.0
• Lazy Loading and Fetching Strategies again, with feeling!
• Lazy Loading and the Entity Framework. How long I can go on like this?

As I said, no matter what you tried, you’ll end up using ObjectQuery<T>.Include(string).

My Proposal:

I am here now to propose my idea. And I am just proposing. What about DataLoadOptions for Entity Framework ObjectContext?! Do You know DataLoadOptions class in Linq to Sql?! Yes, I want to steal the idea and make it fit for Entity Framework. I want to implement a tiny clone of DataLoadOptions for Entity Framework. This would give you an option similar to this:

var context = new NorthwindObjectContext;
var loadOptions = new DataLoadOptions()
DataLoadOptions.LoadWith<Product>(p=>p.Category)
DataLoadOptions.LoadWith<Product>(p=>p.Supplier)

context.LoadOptions = loadOptions;

var products = context.ProductsSet;

Of course this is not going to work by itself. The above is a usage sample, however the implementation of such feature will require some coding, and guess what, I’ll end up using ObjectQuery<T>.Include(string).

Where did I reach?

I am almost done with this idea! The DataLoadOptions class for EF is completed with tests. It worth to mention that this class is not 100% clone of LINQ to SQL DataLoadOptions one! There is a big difference. And I can say for some reason in EF you will not fall in mistakes like cyclic issues (read about it on DataLoadOptions remarks section) for example in LINQ to SQL you cannot do this:

loadOptions.LoadWith<Product>(p=>p.Category);
loadOptions.LoadWith<Category>(c=>c.Products);

But in EF it would be safe because you can control implicitly.

Conclusion:

I hope soon I’ll be able to present a demo code. But for now I can say it will be as reusable code that you’ll have to customize to attache to your EF implementation. I am currently integrating it into KiGG as part of EF flavour of repository on KiGG. At the moment I am writing this post I didn’t comment it to KiGG source control. So keep tuned.