Migrating from LINQ to SQL to Entity Framework: Deferred Loading

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Stephen redd — Fri, 17 Oct 2008 01:41:29 GMT

The lack of automatic deferred loading is a deal-breaker.

I respect the "reasons" for not having it enabled by default, and I understand why many might choose not to use it.

The lack of automatic lazy loading means that EF produces entities that you just CANNOT trust. I don't know about anyone else, but when I get a reference to an object, I EXPECT that when I call one of its properties that the property will not blow up in my face! I EXPECT the property to contain data, and that the data will be valid and accurate.

In EF though, when I call the SalesOrderDetail property I have no way to "know" what I'm going to get back. I might get back nothing... but am I getting nothing because it isn't loaded or because there just wasn't any data in the data store? I might get back an error, but it depends on the kind of property... not that getting an error makes me happy either.

Sure, I can explicitly check to see if data is loaded or not, but the mechanism to perform this check requires that I know a lot about the internals of the entity and the relationships between them. For example, I have to know if the property is a navigation property or not in order to know if I should check loaded. Also, the mechanism to do the IsLoaded check is awkward.

Also, if you pass the entity to another class as a return value... now you might not have the ability to explicitly load the related data at all (no context)... but the entity will still contain the booby-trapped properties.

Then there is the sheer noise of all those checks for loaded data and loads. Even in rather trivial applications I end up with more code just to do checks and loads than I have code to actually use the data.

The weight of all this is massive.

Look guys, the whole point of using something like EF and LINQ to Entities is to make data access simpler and better...

I shouldn't have to be suspicious and paranoid of each and every call to an entity. I shouldn't have to baby-sit the API constantly asking "are you sure" before I call a property. And I shouldn't have to know THAT much about the inner workings and relationships inside my logical model just to be able to use the entity without having my code blowing up in my face.

The whole point of EF was to gain abstraction... not force me to know the logical model inside-and-out.

Sure... I might WANT explicit deferred loading, but I shouldn't be FORCED to it ALL of the time.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Gregory Kornblum — Mon, 20 Oct 2008 06:27:09 GMT

Very good argument Stephen. You should write an article about this instead of a comment to someone else's.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Stephen Redd — Wed, 22 Oct 2008 02:20:09 GMT

Thanks Gregory,

I did write an article about it on my personal site back when I was still angry over the whole thing, but I was a little harsher in that article (strong language warning):

http://reddnet.net/code/ado-net-entity-framework-impressive-powerful-useless/

I do make a point to express the same concerns whenever I see the topic come up and it seems like it might be relevant to the discussion.

I might complain loudly, but I am confident that the data team at Microsoft is hearing this same message, and I am confident that they will fix this issue up in the next major release.

But just in case, I keep complaining :P

And the winner is… LINQ to Entities and the ADO.NET Entity Framework

Eric and the .NET Framework — Mon, 03 Nov 2008 19:55:38 GMT

In 2001 we first demonstrated Object Relational Mapping (ORM) technology for .NET – ObjectSpaces . However

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Allen — Tue, 06 Jan 2009 01:35:54 GMT

There is no way we'll use this if we have to check everything to see if a property is loaded or not. The team better make some changes to that or this thing is DOA. I can't believe they would make such a huge mistake.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Simon Segal — Sat, 10 Jan 2009 06:20:02 GMT

I believe eager and lazy loading should and need to be possible by developers expressing their intent prior to accessing attributes of objects. I want and need to have Fetching Strategies as per the NHibernate implementation. Using fetching strategies I have the option of injecting them and easily distributing and re-distributing them. I demonstrated this with LINQ to SQL here : http://www.simonsegal.net/blog/2008/09/16/linq-to-sql-going-poco-and-more/ and you could do the same by wrapping the .Includes extension method however it doesn't correlate well with lazy loading which causes a friction in developing a satisfying outcome. I would prefer my code not to be tightly coupled to my fetching requirements over time immemorial as they are by sprinking them explicitly throughout using .Includes() and .IsLoaded().

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

TT — Thu, 15 Jan 2009 23:50:14 GMT

The main reason for disabling lazy loading is the risk of loosing control over when and how you hit the database.

Inexperienced developers are protected against making database call in an unwanted manner. So why is it that more Linq2Sql developers don't have more problems with lazy loading even though they statistically would be more inexperienced users?

I think it is because if you if you do the error of calling Linq to .... code unaware of what physical storage that lies behind you would get into performance problems very soon and people learn quickly how to avoid this. You cannot be ignorant of what is being called behind the scenes when doing linq queries. That is one of the many reasons I like Linq2Sql over Entity Framework and even NHibernate since it clearly displays the database scheme you are querying. The database is usually the biggest performance factor in a normal web app so every developer should know the database they are querying.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Ken Smith — Thu, 05 Mar 2009 07:51:59 GMT

An even bigger problem with not having Lazy Loading implemented is that there are times you can call the ".Include()" method in your LINQ, and then by the time LINQ gets around to generating your result, it forgets that you've asked it to include the related objects. For instance, if you use the new {} syntax at the end of your query, none of the navigations that you've asked in the middle of your query are remembered.

See here for instance:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=347543

///<Not working!>

var q2 = from p in ent.Products.Include("Categories")

where p.ProductID == 1

select new

{

Product = p,

SupplierCity = p.Suppliers.City

};

var prod2 = q2.First();

//comment: no eager loading -> prod2.Product.CategoriesReferense.IsLoaded == false

///</Not working!>

Whatever else this does, it certainly violates the principle of least astonishment. It also creates headaches in a number of places, for instance, if you're trying to bind to the results of a query in WPF, and don't have the luxury of checking .IsLoaded() before accessing an object's navigation properties. This definitely needs to get fixed.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

Medyum — Fri, 22 May 2009 14:01:07 GMT

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

hikaye — Tue, 07 Jul 2009 17:41:19 GMT

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

ssk sorgulama — Thu, 23 Jul 2009 17:42:25 GMT

The main reason for disabling lazy loading is the risk of loosing control over when and how you hit the database.

re: Migrating from LINQ to SQL to Entity Framework: Deferred Loading

zerrin egeliler — Thu, 23 Jul 2009 19:55:45 GMT

a very good article da a very useful information ..thank you has to share this information.