Living in the Tech Avalanche Generation

Over the course of the next month or so I will be posting a series on using a set of helper libraries which I refer to as NFetchSpec. I have taken the somewhat unusual course of creating this dedicated post that will act as an index of sorts for this series. Another reason for this aggregated index page is that the title of the series accurately reflects the intent of its content however not so much in a search friendly way and I want to make sure that it can be easily found by people who are interested in using Repositories, Fetching Strategies, Specifications and code only mapping.

NFetchSpec aims to provide a basis for using Repositories, Fetching Strategies, Specifications and Code Only mapping using a Role Driven methodology. Here is some example consumer code of NFetchSpec:

Listing 1.0

var customersStartWithA =
    new Specification<IMakeCustomerPrefered>
        (c => c.CompanyName.StartsWith(”A”));

var fetch = new FetchingStrategy<IMakeCustomerPrefered>(true);

fetch.AddIntentions(new IEagerFetchingIntention[]
{
    EagerFetchingIntention.CreateInstance<IMakeCustomerPrefered,
                                          ICollection<IOrder>>(c => c.Orders)
});

var repo = new CustomerBuyingStatusRepository();

var custs =
    repo.Get<IMakeCustomerPrefered>(customersStartWithA, fetch);

foreach (var cust in custs)
{
    cust.MakePrefered();
}

As described in Part 1.0, a role is an interface that describes a business or system event and can flag our  intention; in the case of the code above, the intention is to make the Customer Preferred. Using NFetchSpec, this style of working (using roles) seeps into all aspects of the code. This is certainly not a requirement to use NFetchSpec and I will give some examples to the contrary as we get deeper into the series of posts, but it is the key reason for developing it. In Listing 1.0 we are using NFetchSpec to create a search predicate using a Specification instance, a Fetching Strategy to determine the most appropriate loading for the role and then finally using the Repository to get a Customer to make preferred. The API of NFetchSpec supports writing code like this, where each of the moving parts can be written in line together, however as mentioned in Part 1.0, one of the benefits of working in this role driven way is that we can use some IoC techniques to discover the correct Specifications and Fetching Strategies based on their implementing a given role, i.e, the interface that is specified to the Repositories .Get<TRole>() method. This is closer to the intended proposed usage:

Listing 2.0

var repo = new CustomerBuyingStatusRepository();

var custs =
    repo.Get<IMakeCustomerPrefered>();

The Code here in Listing 2.0 will instruct the NFetchSpec infrastructure to find a fetching strategy and Specification for this role when the overloaded version of the .Get<TRole>() method is called. This approach makes for an extremely flexible approach, swapping out the most appropriate component – if I don’t like the fetching strategy for a given role, I can simply replace it, facilitating just in time performance tuning (in the case of fetching) as we observe the system over time.

Here are the links to the posts in the series. You might notice that some of the links are not complete meaning that that post is yet to come. I will update this list as new posts make there way out.

Helping the Entity Framework Play it’s <Role> Part 1.0 (posted)

Helping the Entity Framework Play it’s <Role> Part 2.0 (posted)

Helping the Entity Framework Play it’s <Role> Part 3.0 (posted)

Helping the Entity Framework Play it’s <Role> Part 4.0 (posted)

All the code will be available on conclusion with the final post. Just one small thing before signing off, I really want to re-emphasise that it’s a really good idea to watch Udi present the ideas that lead me to attempt accommodating this approach for Entity Framework.