This might be easy, but I was wondering why whenever using the process of eagerly loading that .ToList() has to be used after .Include()?
I know that eagerly loading allows for the loading of related entities along with the main entity for query purposes, but why does .ToList() have to be used?
Is it for a memory purpose or something?
For example:
using (var context = new BloggingContext())
{
// Load all blogs and related posts
var blogs1 = context.Blogs
.Include(b => b.Posts)
.ToList(); // why is this needed?
}
Any explanation/help is greatly appreciated.
It is during the ToList() call when the query will actually be immediately executed. So, your previous Include will setup the projection before hitting the database
Related
I have read about lazy loading from this web site.
Enable or disable LazyLoading
"If we request a list of Students with LazyLoading enabled, the data provider will get all of our students from the DB but each StudentAddress property won’t be loaded until the property will be explicitly accessed."
This statement says that when I set Lazy Loading Enabled = true the related data won't be loaded. However
List<Students> stdList = Datacontext.Students.ToList();
if I set lazy loading enabled = true the above code returns all stundents with their teachers and address. What is the point that I am missing here? Please could someone explain it?
No matter what setting you have, if you use .ToList() it will "enumerate the enumerable". This is very significant, and this phrase should become common knowledge to you.
When .ToList() is used, many things occur. Enumerating the enumerable means that the previous set of how to enumerate the set is now being used to actually iterate through the set and populate the data. What that means is that the previous enumerator (which was stored internally as an Expression Tree) is now going to be sent from Entity Framework to your SQLProvider Factory. That will then convert the object graph from the Expression Tree into SQL and execute the query on the server, thus returning the data and populating your list.
Lazy loading instead of using ToList() would be if you had this IQueryable enumerable, and then iterated that manually loading each element in the set, or only partial elements in the set.
Once you have the list of elements returned, lazy loading will only come in to play if there are navigational properties. If there were related properties, for example if you have an Invoice and you want to get the related Customer information from the customer table. The relation will not explicitly be returned at first, only the invoices. So to get the customer data you could then (while the context was still open, i.e. not disposed) access that via the .Customer reference on your object and it would load. Conversely, to load all the customers during the original enumeration, you could use the .Include() functionality on your queryable, and that would then tell the sql provider factory to use a join when issuing the query.
In your specific example,
List<Students> stdList = Datacontext.Students.ToList();
This will actually not load all of the Teachers and Addresses regardless of if lazy loading is enabled or not. It will only load the students. If you want to lazy load a Teacher, while the Datacontext is still not disposed, you could then use
var firstStudent = stdList.First();
var teacher = firstStudent.Teacher;
//and at this point lazy loading will fetch the teacher
//by issuing **another** query (round trip) to the database
That would only be possible if lazy loading were enabled.
The alternative to this is to eager load, which would include the teachers and addresses. That would look like this
List<Students> stdList = Datacontext.Students
.Include( s => s.Teacher )
.Include( s => s.Address ).ToList();
And then later on if you were to try to access a teacher the context could be disposed and access would still be possible because the data was already loaded.
var firstStudent = stdList.First();
var teacher = firstStudent.Teacher;
//and at this point the teacher was already
//loaded and as a result no additional round trip is required
How was that you noticed that property was loaded, using the debugger? If that is the case, then you already have the answer. With the debugger you are accessing to that property too, so, that also triggers lazy loading.
How this works?
If your entities meets these requirements, then EF will create a proxy class for each of your entities that support change tracking or lazy loading. This way you can load the related entities only when these are accessed. As I explained earlier, the debugger will also trigger lazy loading.
Now, be careful with lazy loading, once you context has been disposed, you will get an exception when you try to get access to one of the related properties. So, I would suggest to use eager loading in that case.
I have tried to implement lazy and eager loading in EF. Everything seems fine, but the .Include() method is available in both cases and returns the same results irrespective of lazy loading false or true.
I have 2 tables categories and product. Category can have multiple products and related using foreign key.
When I load categories using lazy loading by using .Include("Products"), it loads all products related to categories.
Same behavior is shown by eager loading.
var results = objDB.Categories.Include("Products").ToList(); // Enabled lazy load
var results = objDB.Categories.Include("Products").ToList(); // Disabled lazy load
Above both lines have same result. Please clarify this confusion.
.Include should not be available in case of lazy loading = true.
Please give your valuable opinion. Thanks in advance.
When you're explicitly using Include(), you're preforming an Eager Loading. Obviously, disabling/enabling Lazy Loading has no effect.
The difference will be reflected when you'll omit the Include and try to access the Products navigation-property in some of your Category instances. When Lazy-Loading is enabled, EF will load it from the database. When it's disabled, you'll get null.
The difference will be that if you have lazy loading on any entities which are not loaded by the original query will be accessable transparently, and when accessed will trigger an additional query. For example
var results = objDB.Categories.Include("Products").ToList(); // Enabled lazy load
var thing = results.First().Products.First().AnotherEntity;//This will trigger another query and thing will get a value
var results = objDB.Categories.Include("Products").ToList(); // Disabled lazy load
var thing = results.First().Products.First().AnotherEntity;//Thing will be null as its not included in the original result set
FWIW I think most people using lazy loading are causing themselves problems. The only place I would use lazy loading is in a forms/wpf application where people are essentially browsing data in the database and you want to fetch more data as the user clicks things. I don't think there's ever a case for lazy loading in a web application, you are better to be explicit about the data you want from the DB.
Include and ToList are both considered eager methods, so you wouldn't be invoking lazy loading. It's only when you try to access the property of a related entity would the lazy loading feature kick in.
I have an ASP.NET MVC application utilizing Entity Framework for the data layer.
In one of my methods I retrieve the seasonal availability data for a product, and afterwards, the best tax rate for the product.
public ProductList FetchProductSearchList(ProductSearchCriteria criteria)
{
...
var avail = ProductAvailabilityTemplate.Get(criteria.ProductID);
...
var tr = TaxRate.BestMatchFor(criteria.ProductID, criteria.TaxCode);
...
}
In the data layer for ProductAvailabilityTemplate.Get, I had been optimizing the performance of my LINQ code. In particular, I had set ctx.ObjectContext.ContextOptions.LazyLoadingEnabled = false; to prevent EF from loading some entities (via navigation properties) that I don't need in this scenario.
However, once this change was made I noticed that my TaxRates weren't loading fully, because ctx.ObjectContext.ContextOptions.LazyLoadingEnabled was still false in my Tax data layer code. This meant that an entity linked to TaxRate via a navigation property wasn't being loaded.
To overcome this problem I simply set ctx.ObjectContext.ContextOptions.LazyLoadingEnabled = true; in the Tax data layer method, but I am concerned that an unrelated change could cause a problem like this. It seems that you can't safely disable lazy loading for one feature without potentially affecting the operation of whatever is called afterwards. I am tempted to remove all navigation properties, disable lazy loading, and use good old fashioned joins to load exactly what I need for each data layer call, no more no less.
Would welcome any advice.
It's a trade off:
Lazy Loading
gives you the benefit of not needing to specify the depth of graph during loading
will need to return to the database to retrieve missing results
requires some pollution of the POCO's (e.g. virtual properties with proxies)
requires the DbContext to be longer lived, for the duration of all data accesses.
Eager Loading
requires a lot more thought into the depth of loading during each fetch
will typically generate fewer queries with wider joins to fetch the graph at once
does not require any alteration or ceremony around your entities
Allows much shorter lived connections and DbContexts
FWIW, I've generally done prototype work with Lazy Loading enabled, to get software to a demonstrable state, and once the data access patterns stabilize, then switch off Lazy Loading and move to explicitly Included references. A few Unit Tests checking for null references will also do wonders at this point. I am loathe to deliver a production system with Lazy Loading still enabled, as there is an element of non-determinism (e.g. difficult to fully test), and the need to return to the DB for further data will hurt performance.
Either way, I wouldn't switch off all Navigation and do explicit Joins - you are losing the power of navigability that an ORM provides. When you switch out of Lazy Loading, simply explicitly define the entities to be eager loaded with applicable Includes
I was fond of lazy loading when I started using EF, but after a while I realized that it was affecting performance since it effectively disables joins and pulls all subdata in separate queries even if you need to consume it all at once.
So now I'm rather using Includes to eagerly load the sub-entities that I'm interested in. You could also do this somewhat dynamic, for instance by providing a includeDetails parameter:
public IEnumerable<Customer> LoadCustomersStartingWithName(string name, bool includeDetails)
{
using (var db = new MyContext())
{
var customers = db.Customers;
if (includeDetails)
customers = customers.Include(x => x.Orders).Include(x => x.ContactPersons);
customers = customers.Where(x => x.Name.StartsWith(name));
return customers;
}
}
For the code to work in EF6, you would also need to include
using System.Data.Entity;
at the top of the class
The workflow of my app is quite simple:
For a given bunch of scripts
take a script
parse it
get corresponding object graph from db
update it or create new if no graph found
save changes
detach graph from object context for GC could kill the graph
The last item of the list is not necessary if object context is created for each script but it affects performance, moreover I want some of the entities stored in the context whereas others collected by GC.
I thought of manually detaching entities:
foreach (var desc in component.Descriptions)
context.ComponentDescription.Detach(desc);
context.Components.Detach(component);
Such enumeration implies db querying in case of enabled lazy loading. It's not a good thing at all.
I found such a way more like a hack:
var entities = context.ObjectStateManager.GetObjectStateEntries(EntityState.Unchanged).Where(
e => !(e.Entity is ComponentType));
entities.Iterate(e => e.ChangeState(EntityState.Detached));
Well, it's not a graph detaching, but I just know I can do this in my case. But what if I need to work with the certain graph, how can I detach related properties without 'disturbing' db?
As I your question the problem is call to component.Descriptions because it triggers lazy loading if descriptions are not loaded. So the solution should be easy. Temporary disable lazy loading during this operation.
context.ContextOptions.LazyLoadingEnabled = false;
foreach (var desc in component.Descriptions)
context.ComponentDescription.Detach(desc);
context.Components.Detach(component);
context.ContextOptions.LazyLoadingEnabled = true;
I don't understand why do you thing that creating context for each operation affects performance. The reverse is usually true - reusing context affects performance.
I'm currently learning a bit more about Linq-To-Entities - particularly at the moment about eager and lazy loading.
proxy.User.Include("Role").First(u => u.UserId == userId)
This is supposed to load the User, along with any roles that user has. I have a problem, but I also have a question. It's just a simple model created to learn about L2E
I was under the impression that this was designed to make things strongly type - so why do I have to write "Role"? It seems that if I changed the name of the table, then this wouldn't create a compilation error...
My error is this:
The specified type member 'Roles' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported.
The solution below allows me to now write the code:
proxy.User.Include(u => u.Role).First(u => u.UserId == userId)
Which is MUCH nicer!
Include is a hint to eager load, it does not force eager loading.
Always check the IsLoaded property before referencing something that you hope was eager loaded by Include.
There are ways to put a strongly typed object in the include statement, but there is no solution available to this issue out of the box with Entity Framework. Google something like: Entity Framework ObjectQueryExtension Include