When retrieving entities it's common to need to load entities that are related to

the main entity that you're interested in.

For instance, in the previous section when we executed a query to retrieve a list

of comic books, we also needed to load the related artist and

role entities for each comic book in the list.

EF supports three methods for loading related entities.

When equally loading related entities,

you can write a single query that not only retrieves the data for

the main entity, but also the data for the related entities.

The include method is used to tell EF which related entities to load.

With lazy loading the related entities

are not loaded until their navigation properties are accessed.

The process of lazily loading related entities is automatically handled by EF so

it can seem like magic the first time that you see it in action.

As an alternative to lazy loading

you can also explicitly load related entities using the load method.

So far in this course,

we've eagerly loaded related entities using the include method.

Let's take a look at the other two options, lazy and

explicit loading to see how they compare.

If you're following along,

let's start with removing the changes from the previous video.

Here's the original query that we were using to retrieve the list of comic books.

These three include method calls tell EF to eagerly load the series,

comic book artist, artist and role entities.

Let's switch to using lazy loading.

First, let's comment out these three lines of code.

Second, we need to update the comic book and

comic book artist entity navigation properties to be virtual.

We do that by adding the virtual keyword in between the properties axis

modifier and the data type.

And then the ComicBookArtist entity.

Let's run the app and see if we still get the expected output.

And, here's our list of comic books, artists, and their roles.

So how does lazy loading work?

When the in memory representation of our model is being created at runtime

EF will detect that our navigation properties are marked as virtual and

create subclasses for those entities.

Within those subclasses, EF will override our navigation properties.

The overridden properties give EF the ability to detect when those properties

are accessed, and retrieve the data for those properties when it's needed.

The derived entity types that EF creates are called Dynamic Proxies.

Let's run our app again, but this time we'll set a break point

at the beginning of our foreach loop so we can inspect the collection of comic books.

Here we are at our break point.

I hover over the comicBooks variable

to see a preview of the objects in the collection.

Normally we'd expect the value of the items in our collection

to be the fully qualified type name for the ComicBook entity class.

Which are case is, ComicBookGalleryModel.models.ComicBook.

But with lazy loading enabled, the type name is

System.Data.Entity.DynamicProxies.Comic- Book

followed by a long string of letters and numbers.

The long string of letters and numbers is a hash of a generated description for

the Indy that's been subclassed.

Go ahead and remove the break point and press F5 to continue execution.

Now let's look at the queries that were executed by EF to retrieve the data for

our application.

Remember when we were eagerly loading related entities

EF executed a single query to retrieve the necessary data.

With lazy loading enabled multiple queries are needed in order to retrieve the data.

Here's the first query,

the query that EF executed to retrieve the list of ComicBooks.

The second query is to load the ComicBookArtist entities for

the first comic book that was enumerated in our foreach loop.

Notice in the query right here, we can see that we're filtering to the rows

who's comic book ID column values are equal to something named @EntityKeyValue1.

@EntityKeyValue1 is a sequel parameter.

In the comment below that we can see that the EntityKeyValue1 parameter value

was 1, which is the primary key value for the first comic book in the list.

The next four queries are to get the related artist and role entities, for

the first comic book artist entity.

Here's the query to get artist Id1.

And role Id1.

Artist Id2.

And role Id2.

The comic book artist, artist, and roll entities need to be loaded in order

to get the displayed text for the comic book artists and their associated rolls.

The next query is to load the Series entity.

The Series entity needs to be loaded in order to get the displayed text property

value which is a combination of the series title property and

the comic book issue number property.

The next query is to get the ComicBookArtist entities for the comic

book with an Id of two which is the second comic book in our comic books collection.

Then the next query is to get the ComicBookArtist entities for

the comic book with an Id of three.

What happened to the queries to get the related Artist and Role entities for

the second comic book?

Since those entities are the same as the entities for

the first comic book they're already loaded into the context.

EF is able to detect this and associate those entities

with the second comic book without having to retrieve the data a second time.

Now let's look at the third option for loading related entities.

Explicit loading.

To demonstrate explicit loading,

let's remove the virtual keyword from the comic book series navigation property.

Now that we're not eagerly or lazy loading the series navigation property,

the coming book displayed text properties should not work properly.

And sure enough, we're just seeing that issue number for each comic book.

To explicitly load the series navigation property, let's add an if statement just

inside of the foreach loop that checks if the comic book series property is null.

If comicBook.Series == null.

If the property is null then we'll call the context

as entry method passing in the current comicbook context.Entry(comicBook)..

The entry method returns a db entity entry object for the referenced entity.

Every entity that has been materialized and

tracked by the context has a db entity entry object associated with it.

This object exposes two methods that we can use to get the entry objects for

navigation properties.

Reference for non-collection navigation properties and

collection, for navigation collection properties.

The entry objects that are returned by these methods provide a load method

that when called, will load the related entity's.

Since the series property is a non-collection navigation property,

we'll use the reference method to get the entry for the navigation property.

Cb => cb.Series.

Then we'll call load on the returned object.

.Load();.

Calling the load method will execute a query against the database

every time that it's called.

That's why we need to check if the series is null and

only call the load method if we need to,

otherwise we'd end up executing queries for entities that were already loaded.

Now let's test our explicit loading of the series entities.

And our output is back to what it should be.

Let's take a look at the pros and cons of each approach for

loading related entities.

When you see Eager Loading,

there will generally be fewer queries executed against the database.

There are also be fewer surprises as it forces you to plan upfront

with data you'll need for your application.

Of the three options,

Lazy Loading is the easiest to use plus you only load the data that you need.

On the downside,

as we saw in this video, Lazy Loading can result in a lot of queries.

Explicit Loading gives you exact control over the loading process.

Additionally, though we didn't demonstrate it, you can load just part

of a related collection which isn't possible with Eager or Lazy Loading.

The challenge with explicit loading is that it requires

more thought and planning.

I tend to find that I use eager loading more than the other options.

It's relatively easy to use and I like its explicitness.

That being said, every situation is different so consider the tradeoffs of

each option and pick the one that is the best fit for your particular situation.