What about DataLoadOptions for Entity Framework ObjectContext?

by mosessaur| 24 April 2009| 8 Comments

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:

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 as part of EF flavour of repository on . At the moment I am writing this post I didn’t comment it to KiGG source control. So keep tuned.

Comments (8) -

Damien Guard
Damien Guard United States on 4/17/2009 11:45 AM I thought about adding this a while back but the LINQ to SQL method is very restricting. If you want to eager load a bunch of queries in EF it's very simple to just do:

var customerAndOrders = db.Customers.Include("Orders");

then:

var recentOrders = customerAndOrders....

Which gives you much more flexibility than a one-time setting for the lifetime of the context.

[)amien
|
mosessaur
mosessaur Egypt on 4/17/2009 8:27 PM @Damien the chaining of using Include method is exactly what I am using to apply my approach.
I extending the generated ObjectContext class (partial). To apply my way I had to use CreateQuery method with chaining Include method based on the registration made on LoadWith<T> method of DataLoadOptions.

BTW, you have a great blog starting with contents ending with blog theme and colors Wink
|
Simon Segal
Simon Segal Australia on 4/19/2009 5:16 PM Moses

In my view the real problem with Fetching either lazy or eager in Entity Framework, lies in the core of the design, which is disjointed and divergent. If the Entity Framework team can unite both eager and lazy fetching in their API and keep it discrete enough that we don't have to sprinkle our business logic with the infrastructure concerns of fetching instructions, then they will have succeeded in providing a much better solution.
|
mosessaur
mosessaur Egypt on 4/20/2009 1:11 AM @Simon Segal, first of all I am fan of your EF posts and I learned from them too much and I liked the strategy you were using.

And I totally agree with you! But I think at this point it might be very hard to provide such thing in the core of the APIs. It will require a change in the design which might cost much.

I would really like to see that! but I don't think this is not going to happen even in v2 of EF.

Thank you Simon for your comment and for your valuable posts, they are the best I have ever read regarding this subject
|
Simon Segal
Simon Segal Australia on 4/26/2009 5:05 AM Yes I agree that both eager and lazy fetching are likely destined to remain disconnected in the framework, which is a big shame and will for me be one of the biggest drawbacks.
|
Bogdan Brinzarea
Bogdan Brinzarea Romania on 4/21/2009 8:48 AM Hi Moses,
Please take a look at Stuart Little's post.
blogs.msdn.com/.../...query-t-include-updated.aspx

I think that you can rely on that instead of ObjectQuery<T>.Include(string).

I hope this helps,
Bogdan
|
mosessaur
mosessaur Egypt on 4/24/2009 9:41 AM @Bogdan Thank you for the link. It is pretty similar to the first 3 links in the list mentioned in this post. Still we all stuck with .Include() method. We just try to enhance it by using Lamda Expressions instead
|
Melayu Boleh
Melayu Boleh United States on 5/3/2009 10:27 PM In my view the real problem with Fetching either lazy or eager in Entity Framework, lies in the core of the design, which is disjointed and divergent.
|

Pingbacks and trackbacks (5)+

Comments are closed