Tim Mallalieu's Blog.

Just a PM's random musings on data, models, services...

To Lazy Load or not to Lazy load?

To Lazy Load or not to Lazy load?

  • Comments 8

I just exchanged email with Martin Fowler about the term Lazy load. The interpretation that we on the Entity Framework team had about Lazy Loading was that on a given query we would not "eagerly" load an entire graph (i.e. load a customer, their orders, order lines and products...) but instead would, by default, retrieve a shallow version of the queried instances.

 

I believe this definition holds true but is incomplete, according to feedback from Martin. Per our exchange, Martin indicated that the notion of lazy load expects that one does not have to do anything beyond dereference operations to retrieve the related instances. As a result this coding pattern should work:

            using (MSPetShop4Entities context = new MSPetShop4Entities())
            {
                var prod1 = (from p in context.Product select p).FirstOrDefault();
                Console.WriteLine(prod1.Category.Name);                
            }

In the Entity Framework we were concerned that people using our framework would not be aware that the call prod1.Category.Name above would result in a query to the store. The result was that we require that the person be explicit about making the call to the store before doing the dereference:

In order for someone to retrieve the related instances one would call the ".Load" method on the reference or collection to indicate that one was indeed willing to execute a subsequent query to the store.

            using (MSPetShop4Entities context = new MSPetShop4Entities())
            {
                var prod1 = (from p in context.Product select p).FirstOrDefault();
                prod1.CategoryReference.Load();
                Console.WriteLine(prod1.Category.Name);                
            }

I already mentioned in an earlier post how this can cause a leaky abstraction for people trying to abstract EF. We are looking at this pattern in V2. The interesting thing is whether the second example is lazy loading or not. We had been calling this "explicit lazy loading" but, to Martin's point it is an overload of a clear term and we should not do that. I think we will attempt to refer to this as Explicit Loading without introducing the "lazy" overload to try and be clear moving forward.

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • PingBack from http://stocks-options-trading.info/trading-strategy/?p=1092

  • Lazy Loading has been discussed at length, its in books, its discussed in blogs, its been implemented many times including by ORMs...I'm thus slightly confused as to how this misunderstanding could have happened.

  • Explicit is more clear given how it is working  

  • Well to play devil's advocate...

    What do you call .Include("Customer")

  • As someone who favored the explicit over "magic" for many years I understand your concerns.  In recent years I've adopted many "ALT.NET" technologies including NHibernate.  Let me say that once you put your faith in the underlying framework to do the magic there's no going back.  Sure, there's a call to the backing store that you aren't in control of, but that's the point to some extent.  When that call is made is decided by whomever designed the entities and their mappings.  More than likely that person is someone who understands the ramifications of lazy vs. eager loads in different scenarios.  I'd rather let the framework do my dirty work these days and concentrate on what actually earns measurable returns.

  • [quote]

    Well to play devil's advocate...

    What do you call .Include("Customer")

    [/quote]

    I would call that eager loading. ("explicit eager loading" maybe, since a single, specific property is requested?)

  • [quote]

    Well to play devil's advocate...

    What do you call .Include("Customer")

    [/quote]

    I would call that "eager loading" since it's occurring at the same time the parent is fetched. ("explicit eager loading" maybe, since a single, specific property is requested?)

  • How about 'Explicit Delayed Loading' or 'Explicit just-in-time Loading' or something like that?

    Perhaps we should change 'lazy loading' to be 'transparent just-in-time loading' or 'transparent lazy loading' to be more precise?

    In my experience, Lazy Loading was scary at first, but once you got used to it and where it's appropriate to turn it on and there's it's appropriate to turn it off (i.e. NHib will load that part of the graph every time), it really is a huge boon to productivity.  In my experience, the DB is actually pretty good at handling a lot of little requests like that, it's the big ones you have to look out for.

    Lazy loading requires some thought/planning on the mapping side and some analysis during testing to make sure it's optimized, but overall I think it's a big plus and definitely worth getting used to.

Page 1 of 1 (8 items)