Living in the Tech Avalanche Generation

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

March 5th, 2009 Simon Segal 4 comments

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.

Categories: Entity Framework, LINQ, ORM Tags: Entity Framework, LINQ, ORM

LINQ To SQL, Dynamic Querying & Fetching Strategies (cont)

July 15th, 2008 Simon Segal 4 comments

I posted recently on using the Specification Pattern and utilizing the generic Expression<> and Func<> to dynamically change the criteria of SQL queries generated by the LINQ To SQL implementation. I promised to come back with an approach on enabling Eager Loading by implementing a Fetching strategy, that can be used with my Repository. Here’s the Fetching Strategy code (most of it).

   1:  public interface IFetchingStrategy

   2:  {

   3:      DataLoadOptions LoadOptions { get; }

   4:  }

5:

   6:  public interface IFetchingStrategy<TRole> : IFetchingStrategy

   7:  {

8:

   9:  }

10:

  11:  public interface ICustomerLoyaltyDiscount

  12:  {

13:

  14:  }

15:

  16:  public class CustomerLoyaltyDiscountFetchingStrategy :

  17:                   IFetchingStrategy<ICustomerLoyaltyDiscount>

  18:  {

  19:      private readonly DataLoadOptions _loadOptions;

20:

  21:      public DataLoadOptions LoadOptions

  22:      {

  23:          get { return _loadOptions; }

  24:      }

25:

  26:      public CustomerLoyaltyDiscountFetchingStrategy()

  27:      {

  28:          _loadOptions = new DataLoadOptions();

  29:          _loadOptions.LoadWith<Customer>(c => c.Orders);

  30:          _loadOptions.LoadWith<Order>(o => o.OrderLines);

  31:      }

  32:  }

Most of the code above is self explanatory except perhaps for the interface ICustomerLoyaltyDiscount on line 11. This interface is used to describe a role in my repository so I can dynamically lookup Fetching Strategies that take that role as a generic parameter and use them to fetch data.

   1:  internal static void SimpleRepositoryDynamicFetching()

   2:  {

   3:      Specification<poco.Customer> simonsCoSpec =

   4:          new Specification<poco.Customer>

   5:              (c => c.Country == "Germany");

6:

   7:      DataContext ctx = GetContext();

8:

   9:      Repository<poco.Customer> customerRepository =

  10:          new Repository<poco.Customer>(ctx);

11:

  12:      var custs = customerRepository.

  13:               All<ext.ICustomerLoyaltyDiscount>(simonsCoSpec);

14:

  15:      foreach (var cust in custs)

  16:      {

  17:          Console.WriteLine("The Name of the Customer " +

  18:                   "from Germany is {0}",

  19:                   cust.CompanyName);

  20:          foreach (var order in cust.Orders)

  21:          {

  22:              Console.WriteLine("\tOrder Number {0}",

  23:                               order.OrderID);

  24:              foreach (var orderLine in order.OrderLines)

  25:              {

  26:                  Console.WriteLine("\t\tProduct ID {0} " +

  27:                      "Amount {1}",

  28:                      orderLine.ProductID,

  29:                      (orderLine.Quantity *

  30:                        orderLine.UnitPrice));

  31:              }

  32:          }

  33:      }

  34:  }

As you can see from the code above, when I call the Repository ALL method (as shown below), I use the overload that takes a generic parameter, indicating to the repository to look for a Fetching Strategy that also has this generic argument defined as its role.

   1:  public IList<T> All<TRole>(ISpecification<T> spec)

   2:  {

   3:      using (_context)

   4:      {

   5:          ext.IFetchingStrategy<TRole> strategy =

   6:              DynamicFetchingStrategyLoad<TRole>();

   7:          _context.LoadOptions = strategy.LoadOptions;

   8:          return GetTable().Where(spec.EvalPredicate).

   9:                            ToList<T>();

  10:      }

  11:  }

The next time I post on this subject I will include the entire code, repository, specifications and fetching strategies.

Categories: C#, Design Patterns, LINQ, LINQ To SQL, TSQL Tags: C#, Design Patterns, LINQ, LINQ To SQL, TSQL

LINQ to SQL, the Specification Pattern and Dynamic Queries

July 2nd, 2008 Simon Segal 1 comment

A while back Udi posted on Fetching Strategies that he implemented with NHibernate. I have just finished working on an implementation of the Specification Pattern that will work with LINQ (to objects) using Lambdas to provide the test logic and in the case of LINQ to SQL using the same testing predicates as search predicates when querying the database.

   1:  public static void SpecForLambdaWithDatabase()

   2:  {

   3:      Specification<Customer> coNameSpec =

   4:          new Specification<Customer>

   5:              (c => c.CompanyName == “Blauer See Delikatessen”);

6:

   7:      NorthwindDataContext ctx = new NorthwindDataContext();

8:

   9:      //TODO: Turn this into a fetching strategy that

  10:      //can be loaded when a Repository method is called

  11:      //using a role. Dependancy Injection will be useful

  12:      //in allowing us slot in different fetching strategies

  13:      //over time if required.

  14:      DataLoadOptions options = new DataLoadOptions();

  15:      options.LoadWith<Customer>(c => c.Orders);

  16:      options.LoadWith<Order>(o => o.OrderLines);

  17:      ctx.LoadOptions = options;

18:

  19:      //Note: the specification passes it’s EvalPredicate

  20:      //as a Func<T,bool> argument to the ‘Where’

  21:      //extension method

  22:      var exp = from c in ctx.Customers

  23:                .Where<Customer>(coNameSpec.EvalPredicate)

  24:                select c;

25:

  26:      foreach(var c in exp)

  27:      {

  28:          Console.WriteLine(“The Customer ID ‘{0}’ “ +

  29:              “AND NAME ‘{1}’”,

  30:              c.CustomerID, c.CompanyName);

  31:      }

  32:  }

My next goal is to enable the eager and lazy loading in these scenarios dealt with by using something similar to Fetching Strategies and have the Repository load them using dependency injection which will enable me to plug in the correct fetching strategy at will.

Shortly I will post some code that demonstrates all this with a Repository and not the standard .DBML file, DataContext way of doing things as per above.