Living in the Tech Avalanche Generation

Lazy Loading and the Entity Framework. How long I can go on like this?

March 05th, 2009 | Category: Entity Framework, LINQ, ORM

In more recent times I have spent a fair slice of time looking at how to get lazy loading working in the Entity Framework (without using the codeplex solution). Oddly, the driver for this was to get Fetching Strategies implemented for the Entity Framework and not the other way around and I have devoted a quite a few posts recently to that.

If you have followed the story until now, then you will know that I developed a method of transparently lazy loading by using some AOP style trickery and weaving code into the Entities themselves. I did say that I wasn’t going to post on this but it will become apparent why I chose to liberally change my mind about that as we move through this post. Currently the way to have your entity ‘opt’ into lazy loading (with my code), is to decorate it with an attribute in the partial class representation of the Entity itself.

[LazyLoad("Customer", AttributeTargetMembers = @"regex:(Customer$)")]
[LazyLoad("Order_Details", AttributeTargetMembers = @"regex:(Order_Details$)")]
public partial class Order : IFetchable
{
    private IFetchingStrategy _strategy;
    public IFetchingStrategy FetchingStrategy
    {
        get { return _strategy; }
        set { _strategy = value; }
    }
}

Note that this attribute is already written and part of the code download, you don’t have to write any PostSharp attributes yourself to get the code to work. Once having applied the attribute and compiled, PostSharp kicks in and weaves code where it’s directed, in this case the Order entities Customer and Order_Details properties. A look at the code in Reflector confirms this:

Now cool as PostSharp is, this is not a job I was hoping to have to have ever used it for. Entity Framework shouldn’t need that much work for transparent lazy loading and we are promised that will change in a later (next?) version. The lazy loading however is only part of the story. As much as I want transparent Lazy Loading OOTB, I equally need the Eager Loading story to be dealt with. As I have said throughout this series of posts, part of the fetching strategy problem lies in the disconnect between Lazy and Eager fetching and something tells that I will still be rewriting this solution for a later version of Entity Framework.

While we are waiting…..

This solution isn’t proven in battle and needs a lot more work to verify it’s bona fides, but I will push it forward on very small, low risk projects to see how it pans out. I for one really want the Entity Framework to ‘make good’ and reach the hearts and minds of the POCO and DDD audience into the bargain. The question is how long am I prepared to wait and ‘go via the cape’?

Step by Step

Download the code
Copy the LazyLoadAttribute.cs file into your project with an entity model
Reference the PostSharp.Laos, PostSharp.Public libraries.
Reference the Org.TechAvalanche.Orm.Repository library
Decorate the Partial class representation of your Entity with the LazyLoad attribute (copied in the second step) and your done. Write your fetching strategies, Repositories and Specifications and away you go.

I will soon follow with an Item Template for VS.Net that creates the attribute file and makes the references for you automatically.

4 Comments so far

Alex James March 6th, 2009 1:49 am

Simon,

Udi pointed me at this. Very cool BTW. As for a couple of your questions:

1) Lazy-loading can easily be turned on in EF in the Next version (i.e. in .NET 4.0). You simply set an option on the Context.
2) I haven’t read all of the (interesting) series of posts you’ve done on EF yet, so I’m not quite sure where the friction is with EF’s eager loading. What’s the problem exactly?

Anyway. Thanks for the excellent informative post. I will definitely be going back over your earlier posts as soon as I get a chance.

Cheers
Alex

[Reply]
Simon Segal March 6th, 2009 8:08 am
Alex
1. Nice to hear about the lazy loading coming in 4.0.
2. The friction with eager loading is that it’s implementation is disconnected from that of lazy loadings. I understand that the mechanism for both are quite different and hence the implementation differences, however it is key in defining my performance characteristics to be able to declare my entire loading ‘intention’ in one go and my preference is to declare that intention to my repository when I ask it to fetch data. This is the reason I have borrowed the ‘fetching strategy’ concept, to encapsulate my entire intent and submit it to the framework once and furthermore not have any fetching code intermingled with my entities business logic (which POCO will round out for me even further). The next aspect that I need to implement in my code demonstrated in this series of posts, goes another step further and makes it possible for me to declare my fetching intention by specifying an interface as a role and by implementing a fetching strategy that implements that given role, I can dynamically interchange my intention on how to fetch data. Again that approach is tied to what effect on loading my business logic is going to have. Part 9.0 in the series of posts best reflects this concern.
Thanks for the feedback.

Simon

[Reply]
Living in the Tech Avalanche Generation » Entity Framework Profiler – When .ToTraceString() just isn’t enough! March 31st, 2009 1:18 pm

[...] or any other ORM if I choose to and it’s true that I went to the extent of developing my own lite framework to enable me in pursuing this preferred ’style’ of work with the Entity [...]
Living in the Tech Avalanche Generation » Entity Framework Repository Testing April 27th, 2009 10:35 pm

[...] recently asked about testing the Repository / Fetching Strategy / Specification framework that I posted a while back. We can in fact bypass integration testing and by doing some state based testing on [...]