Living in the Tech Avalanche Generation

Simon:

I like the idea and I’ve been working with something similar. Couple questions:

- What if you used IFetchingStrategy to get strongly typed code? Like: new FetchingIntention(c => c.Orders, FetchMode.Eager). Using an Expression as the first parameter would make it relatively easy to dig the out a string value for the property name(s) and then .Include() it in EF. The benefit being you never have to worry about magic strings.

- Curious: why do you need “AsIList” as a suffix on the repository method?

Looking forward to more.

[Reply]

Hi Scott

Yes the magic strings were a smell on my radar and thanks for the neat solution, the expression is much better and in keeping with one of reasons I was keen to keep at it with EF (LINQ).

The AsIList() method will possibly be accompanied by an AsIQueryable() and perhaps even an AsObjectQuery() overload so I am not forcing IList’s on the user. IList is my preferred way of working however as much of my data access work will occur in a service layer and I wont be holding on to long lived ObjectContext’s.

Thanks,

Simon

[Reply]

Simon,
I can’t tell you how much I’m waiting for the follow up artice after the tease at the end there.
I’ve got round the lazy load at the moment using aspects but I’d rather not have to do it if at all possible.
The lack of lazy load is the one thing that really irks me about EF, for me it’s correctness first, optimization second. I know lazy relations are network calls, I don’t need to write more code to remind myself.
Keep up the great posts - they’re appreciated,
Paul

[Reply]

Paul

I’m afraid I wont be relieving you or anyone else from using an ASPECT. After looking at your implementation for lazy load just now, I can tell you that mine is very similar and I too used postsharp to achieve it. I share your frustration and agree with all your points re the rationale of why we have been pushed down this path with EF and why we would prefer it weren’t so. What I am trying to achieve in the broader sense, is to enable myself with a framework that will allow me to unify how I build my repositories, apply dynamic querying (via the Specifications) and declare my intent explicitly about fetching (eager or lazy). Whilst lazy loading has been enormously frustrating I equally do not wish to pollute my business logic with eager loading instructions. If I place all my business logic for an entity in my partial class that extends the EF entity, I don’t want any infrastructure code in there at all and I want my methods to know explicitly what to load and not load. This is achieved by using Roles (an approach I picked up from Udi Dahan). I can use generic method argument to express my role under which I request my business entity to behave. Perhaps best exemplified by way of an example?

public interface ICustomerMakePrefered
{
     public void MakePrefered;
}

public partial class Customer : ICustomerMakePrefered
{
    public void MakePrefered()
    {
        // I should eager fetch becuase
        // I expect that I might get thousands
        // of orders and lines.
        // My pre-loaded fetching strategy has
        // taken care of this for me ahead of time.
        foreach (var order in this.Orders)
        {
            foreach (var orderline in order.OrderLines)
            {
                orderline.price -= (orderline.price * 0.1);
            }
        }
    }
}

public class MarketingService
{
    public void MakeCustomerPrefered()
    {
        Repository<Customer> cust_repos =
            new Repository<Customer>();
        //get the relevant customer
        //and set the entity so it knows
        //what it’s fetching strategy should
        //be based on the explicit role of
        //making it prefered
        var cust = cust_repos.Get<ICustomerMakePrefered>(“ALFKI”);
        //make the customer prefered 
        cust.MakePrefered();
    }
}

public class Repository<TEntity> where TEntity : class, new()
{
    public TEntity Get<TRole>(string custId)
    {
        // get the instance of T and finds (via reflection) 
        // any assemblies that contain a loading strategy
        // that implements TRole. When using EF to get
        // the Entity via the ObjectContext, I can use
        // the found Fetching Strategy to load appropriately.
        // This allows me to drop new FetchingStrategies in
        // and out at will.
        //…… use ObjectContext to get setup my query
        //PLEASE NOTE: this is not the exact implementation
        //of my repository.
    }
}

[Reply]

Hi Simon,

It all looks really nice, I’ve been following your blog for a while now so I’ve seen your journey to this point. The approach you’ve taken seems really clean, I really do like the way you can tune the loading strategies on a use-case by use-case basis.

Paul

[Reply]

Simon,

Very elegant. I hope the next version has an update to the Fetching Intention to remove the magic strings.

Mark

[Reply]

Hello Simon,

Thank you for your great work!

I searched for the code of the remarkable .AllAsIList method. But I can’t find that. Where can I find it?

With friendly greetings,
Pieter
The Netherlands

[Reply]

Hello Simon,

Thank you for your quick answer. But at the referenced location I can’t find the code for
AllAsIList(“Customers”, german_cust_spec, new
MultiLevelMixedStrategy());

With friendly greetings,
Pieter
The Netherlands

[Reply]