Transparent Lazy Loading for Entity Framework – part 1

This post is a part of the series that describes EFLazyLoading library.

The first release of Entity Framework supports explicit loading. This means that if you are navigating a relationship, you have to make sure it is loaded by explicitly calling Load()on EntityReference<T> or EntityCollection<T> objects, or pre-loading your relationships by using Include() on your query.

If you try to navigate a many-to-one or one-to-one relationship that is not loaded, you will get a NullReferenceException. In case of EntityCollection<T> that has not been loaded you will silently get an empty collection which may lead to subtle bugs.

One of the benefits of explicit loading is that you can easily locate all places in your code that cause database round-trips. Unfortunately general-purpose code that can be used in multiple units of work (such as validation, permission checks, etc.) does not typically know which relationships have been loaded. Because of that it always has to check whether the relationship being navigated has been loaded, and call Load() if not.

As you can imagine this can easily lead to code that is cluttered with IsLoaded/Load():

var prod = entities.Products.First();
var supplier = prod.Supplier;
foreach (OrderDetail det in prod.OrderDetails)
    if (!det.OrderReference.IsLoaded)
    Console.WriteLine("{0} {1}", det.Product.ProductName, det.Order.OrderDate);

Transparent lazy loading is a way to make your business logic code more readable by handling loads under the hood. As a result you get an illusion of a fully populated object graph, so the above example can be re-written as:

var prod = entities.Products.First();
var supplier = prod.Supplier;
foreach (OrderDetail det in prod.OrderDetails)
    Console.WriteLine("{0} {1}", det.Product.ProductName, det.Order.OrderDate);

This simplicity comes at a cost:

– Database queries are more difficult to locate (potentially any relationship navigation can lead to a query)

– Object graph is fully populated so you cannot easily serialize parts of it without using DTO (Data Transfer Objects). Carelessly returning an object from a web service could potentially bring in the entire database with it.

As we said, Entity Framework v1 supports explicit loading only, but the object layer code is something the developer can control, either by writing it by hand or creating a tool to do so. We just need to inject Load() method call in a few places. Sounds simple?

Strategies for implementing transparent lazy loading

There are two main strategies when implementing transparent lazy loading. One approach is to fully materialize related objects whenever you access them – let’s call this approach Lazy Initialization.

Lazy Initialization is easy do in Entity Framework – all you have to do is to add extra code to do Load() in property getters that are used to navigate relationships (see Danny’s post about codegen events).

The following code checks whether the relationship has been loaded and forces Load() if it has not – this frees the business logic to focus on business rules rather than plumbing (note that this source code change only works with attached objects – detached objects require special handling – not shown here):

[EdmRelationshipNavigationProperty("NorthwindEFModel", "Products_Supplier", "Supplier")]
public Supplier Supplier
        // added code 
        if (!SupplierReference.IsLoaded)
        return ((IEntityWithRelationships)(this)).RelationshipManager.
            GetRelatedReference<Supplier>("NorthwindEFModel.Products_Supplier", "Supplier").Value;
            GetRelatedReference<Supplier>("NorthwindEFModel.Products_Supplier", "Supplier").Value = value;

The result is that product.Supplier is always accessible, which is what we wanted. Unfortunately fully materializing related objects is not always desirable for performance reasons. There are cases where you do not care about related object attributes, but the object itself is interesting to you. Consider an example function ShareManager that returns true when two employees share the same manager and false otherwise:

bool ShareManager(Employee emp1, Employee emp2)
    if (emp1.Manager == emp2.Manager)
        return true;
        return false;

By merely touching emp1.Manager and emp2.Manager, we have potentially caused two Manager entities to materialize (and that means two database queries), while we were just interested in checking whether they are the same object.

In Entity Framework you can reason about identities of related objects without materializing them by examining EntityKey property on EntityReference<T>. So our example can be re-written for performance as:

bool ShareManager(Employee emp1, Employee emp2)
    if (emp1.ManagerReference.EntityKey == emp2.ManagerReference.EntityKey)
        return true;
        return false;


But that is not nearly as nice as the first code snippet because you have to deal with EntityKeys now.

Fortunately it turns out that with some clever code generation it is possible to have the first syntax and not pay the price for object materialization except when it is absolutely needed. Intrigued? Stay tuned for Part 2 where I will introduce a lazy loading framework (code generator and supporting library) for EF.

The strategy that will be used is based on an observation that you do not need to materialize an object if you do not access its non-key properties…


The code for EFLazyLoading library can be downloaded from

The second part of this article is available here

Comments (18)

  1. Meta-Me says:

    Most of you probably know that the Entity Framework architects made a very conscious decision to make

  2. There’s a lot going on today! Not only has VS 2008 SP1 Beta been released (with the EF fully integrated

  3. Diego's Blog says:

    Recently, I wrote a small article that got published in the new Insights sidebar in MSDN Magazine. There,

  4. As I promised last time , I would like to present the result of a little experiment in implementing transparent

  5. Régulièrement quand je parle de l’Entity Framework, on me reproche très souvent l’absence de Lazy Loading.

  6. Entity Framework FAQ Version 0.4 – 5/13/2008 New in this version of the FAQ… · Major Update for VS 2008

  7. Hot Topics says:

    There has been a lot of discussions lately about Entity Framework and Lazy Loading as well as some solutions

  8. Jaroslaw Kowalski napsal pěkné posty o tom, jak "vyrobit" transparent lazy loading v EF a připravil i

  9. chadmyers says:

    It may be transparent on the outside, but that’s a lot of work to implement it — work the tool should be doing.

    You could do all this work for all your entities, or you could just use [every other ORM that’s been on the market for years].

    I’m still not sure why people would subject themselves to this sub-par product when just about every other offering on the market is far superior in every respect.

  10. In two previous articles ( part1 and part2 ) I have introduced EFLazyLoading &#8211; a framework for

  11. SiTox.NET says:

    Ar dažām jaunām tehnoloģijām ir tā, ka tās izlaiž, parāda kaut kādas jaunas „features”, bet praksē tie

  12. 江南白衣 says:

    The Entity Framework enables developers to reason about and write queries in terms of the EDM model rather than the logical schema of tables, joins, foreign keys, and so on. Many enterprise systems have multiple applications/databases with varying degrees

  13. Hot Topics says:

    Jarek Kowalski continues his series on implementing Transparent Lazy Loading in the EF. &#160; Part 1

  14. Jarek Kowalski napsal pěkné posty o tom, jak "vyrobit" transparent lazy loading v EF a připravil i prográmek

  15. Ido Flatow says:

    כשהחלטתי בזמנו לכתוב את הפוסטים שלי בעברית, שיערתי שיגיע היום שבו לא אוכל לתרגם מושגים לעברית כך שזה

  16. Part of the Entity Framework FAQ . 9. Object Services 9.1. What is ObjectContext.Detach() method used

  17. Ido Flatow says:

    I&#39;ve received a couple of request to write some of my previous posts in English so that all other