Interactive Extensions as a PCL

Posted Tuesday, October 29, 2013 by

Interactive Extensions is a fantastic library from the team that brought us Reactive Extensions, in fact it supports a lot same operations on IEnumerable that Rx brought to IObservable.

The best way to think about it is that it's a library that takes Linq to the next level, there's a nice summary at Interactive Extensions for LINQ to Objects.

However while Ix has been available as a Portable Class Library for a while now it didn't include the appropriate flags for WinRT development. But now it does! Checked in last month to the source was an update to allow it to be used in WinRT, it's not yet published to nuget but I'd highly recommend checking it out.

Some useful async extension methods

Posted Tuesday, April 30, 2013 by

Linq is awesome, async / await is awesome, but combining them can be a little awkward. None of the standard linq operations are written to deal with async lambdas, this often leads to writing the async operations in a more procedural style approach rather than the functional one that Linq uses.

Here's a couple of useful extension methods I use, WhenAllAsync allows you to execute an aysnc method on a sequence of values. By using Task.WhenAll we can have the async method execute in parallel with each other.

public static Task WhenAllAsync<T>(this IEnumerable<T> values, Func<T, Task> asyncAction)

{

    return Task.WhenAll(values.Select(asyncAction));

}

The usage is pretty self explanatory, the only odd bit is that because DeleteAsync returns an IAsyncOperation rather than Task we use AsTask to convert it (or if you want right a second extension method using IAsyncOperation).

var files = await GetFilesAsync();

 

await files.WhenAllAsync(f => f.DeleteAsync().AsTask());

SelectAsync is useful for transforming a collection of values to another type via an asynchronous method. It's much like WhenAllAsync except that we return the result of the operation.

public static async Task<IEnumerable<TResult>> SelectAsync<TSource, TResult>(this IEnumerable<TSource> values, Func<TSource, Task<TResult>> asyncSelector)

{

    return await Task.WhenAll(values.Select(asyncSelector));

}

var images = await GetFilesAsync();

 

var streams = await files.SelectAsync(f => f.OpenAsync(FileAccessMode.Read).AsTask());

Hopefully these help you write more readable performant async code.

Unit of Work per Action

Posted Monday, July 19, 2010 by

Most of the time I do any database interaction I follow a "Unit of Work" pattern. This allows good control over when work is submitted to the database, in terms of the Entity Framework, the Unit of Work controls the lifetime of the ObjectContext.

The implementation is pretty simple, we have a UnitOfWork static class that provides easy access to the current UOW as well as starting and disposing. We then have our IUnitOfWork which is where the work of accessing repositories and submitting changes to the database will be done. We then implement that with EntityUnitOfWork.

I like to follow the approach of "Unit of Work per Request" for web applications and usually handle this with an IHttpModule that manages it for me. However for MVC I wanted to try something different. One of the reasons I didn't like Module approach for MVC was that the UnitOfWork was still active during the rendering of the View. This meant that any complex lazy loaded queries could still be evaluated which could leave me vulnerable to N+1 problems.

public class UnitOfWorkAttribute : ActionFilterAttribute

{

    public override void OnActionExecuting(ActionExecutingContext filterContext)

    {

        UnitOfWork.Start();

    }

 

    public override void OnActionExecuted(ActionExecutedContext filterContext)

    {

        if(UnitOfWork.IsStarted)

            UnitOfWork.Dispose();

    }

}

In the end I created a UnitOfWorkAttribute which inherits from ActionFilterAttribute, this enables me to dispose of the current unit of work after the action is completed but before the view is processed. It means that if the view triggers anything that causes database access it throws an error. I can now enforce the convention that all data must be loaded by the action.

[HttpPost, UnitOfWork, ActionName("sign-in")]

public ActionResult SignIn(SignInViewModel details, string returnUrl)

Entity Framework Repositories

Posted Thursday, June 10, 2010 by

A long time ago I wrote a few posts about using "Domain Driven Design"-esque repositories using Linq to SQL ("Domain Driven Design Repositories in Linq to SQL"). I still use that general pattern with a few tweaks with extra layer of a "Unit of Work" to manage context lifetimes. I'm using this rebuild as a chance to play with Entity Framework 4 and so need to implement the appropriate interfaces all over again. The only major functionality change will be bringing in support for Entity Frameworks "Include".

I'm not going to go over the full pattern here, just the new parts for Entity Framework, the IRepository interface has changed that GetAll returns an interface IQuery which is pretty much the IQueryable interface with the Include method.

The implementations for IQuery and IRepository are as follows.

public class EntityRepository<T> : IRepository<T> where T : class

{

    private readonly ObjectSet<T> objectSet;

 

    public EntityRepository(ObjectSet<T> objectSet)

    {

        this.objectSet = objectSet;

    }

 

    public IQuery<T> GetAll()

    {

        return new EntityQuery<T>(objectSet);

    }

 

    public void Save(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        objectSet.AddObject(entity);

    }

 

    public void Update(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        objectSet.Attach(entity);

    }

 

    public void Delete(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        objectSet.DeleteObject(entity);

    }

}

public class EntityQuery<T> : IQuery<T>

{

    private readonly ObjectQuery<T> query;

 

    public EntityQuery(ObjectQuery<T> query)

    {

        this.query = query;

    }

 

    public IQuery<T> Include(string path)

    {

        return new EntityQuery<T>(query.Include(path));

    }

 

    IEnumerator<T> IEnumerable<T>.GetEnumerator()

    {

        return ((IEnumerable<T>)query).GetEnumerator();

    }

 

    IEnumerator IEnumerable.GetEnumerator()

    {

        return ((IEnumerable)query).GetEnumerator();

    }

 

    Expression IQueryable.Expression

    {

        get

        {

            return ((IQueryable)query).Expression;

        }

    }

 

    Type IQueryable.ElementType

    {

        get

        {

            return ((IQueryable)query).ElementType;

        }

    }

 

    IQueryProvider IQueryable.Provider

    {

        get

        {

            return ((IQueryable)query).Provider;

        }

    }

}

The actual Repository that gets used by the domain layer simply delegates all it's work back to a internal repository based off the current unit of work. This is important section because it decouples the domain repository from repository doing the actual work and allows me to change the underlying data source if necessary.

public class Repository<T> : IRepository<T> where T : class

{

    private static IRepository<T> Current

    {

        get

        {

            return UnitOfWork.Current.CreateRepository<T>();

        }

    }

 

    public virtual IQuery<T> GetAll()

    {

        return Current.GetAll();

    }

 

    public virtual void Save(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        Current.Save(entity);

    }

 

    public virtual void Update(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        Current.Update(entity);

    }

 

    public virtual void Delete(T entity)

    {

        if (entity == null)

            throw new ArgumentNullException("entity");

 

        Current.Delete(entity);

    }

}

I'll get into the Unit of Work stuff in my next post.

Implementing an ActiveRecord pattern in Linq to SQL

Posted Monday, September 8, 2008 by

In earlier posts I talked about about creating Domain Driven Design style repositories using Linq to SQL. These allowed us to swap between Linq to SQL repositories and In Memory ones easily (and really anything that could support IQueryable<T>, this ensured some very nice testabiliy. In this post I thought I'd go over some it again as well as a some refactoring I had done to simplfy things, as well as how to create simple Active Record style data access on top of our repositories and therefore still ensuring our testability.

Our IUnitOfWork and its implementations (SqlUnitOfWork and InMemoryUnitOfWork) haven't changed. However given that IDataSource<T> and IRepository<T> are essentially the same I decided to remove IDataSource<T>. Now that we have two implentations of IRepository<T> (InMemoryRepository and SqlRepository) we need one that uses these repositories and forms the base class for our aggregate repositories.

This base Repository<T> forms the foundation for it all, internally it's only really a decorator around the actual specialised repository that's accessed from the current Unit Of Work (more about this in a later post).

public class Repository<T> : IRepository<T> where T : class

{

    public static IRepository<T> Current

    {

        get

        {

            return UnitOfWork.Current.GetRepository<T>();

        }

    }

 

    public Repository()

    {

 

    }

 

    public IQueryable<T> GetAll()

    {

        return Current;

    }

 

    public virtual void Update(T entity)

    {

        Current.Update(entity);

    }

 

    public virtual void Update(IEnumerable<T> entities)

    {

        Current.Update(entities);

    }

 

    public virtual void Delete(T entity)

    {

        Current.Delete(entity);

    }

 

    public virtual void Delete(IEnumerable<T> entities)

    {

        Current.Delete(entities);

    }

 

    public virtual void Save(T entity)

    {

        Current.Save(entity);

    }

 

    public virtual void Save(IEnumerable<T> entities)

    {

        Current.Save(entities);

    }

 

    public IEnumerator<T> GetEnumerator()

    {

        return Current.GetEnumerator();

    }

 

    IEnumerator IEnumerable.GetEnumerator()

    {

        return GetEnumerator();

    }

 

    Type IQueryable.ElementType

    {

        get { return Current.ElementType; }

    }

 

    Expression IQueryable.Expression

    {

        get { return Current.Expression; }

    }

 

    IQueryProvider IQueryable.Provider

    {

        get { return Current.Provider; }

    }

}

 

Active Record, this seems to be the way a lot of people think data access should be, a few static methods on your classes and away you go. From a testability point of view I feel repositories certainly work better, but for smaller data driven applications Active Record can certainly be the way to go.

I'd like to support both camps with this system so lets build on top of what we already have, first we'll need a static accessor to the current repository, we can do that through the unit of work, but since we already that in our base class we'll just expose that. Now anytime we need our repository it can be accessed through Repositor<T>.Current. This lets us built our ActiveRecordBase.

public abstract class ActiveRecordBase<T> where T : ActiveRecordBase<T>, IIdentifiable

{

    public static IQueryable<T> GetAll()

    {

        return Repository<T>.Current;

    }

 

    public static T GetById(int id)

    {

        return GetAll().Where(i => i.Id == id).FirstOrDefault();

    }

 

    public static IQueryable<T> Find(Expression<Func<T, bool>> predicate)

    {

        return GetAll().Where(predicate);

    }

 

    public static void Save(T entity)

    {

        Repository<T>.Current.Save(entity);

    }

 

    public static void Update(T entity)

    {

        Repository<T>.Current.Update(entity);

    }

 

    public static void Delete(T entity)

    {

        Repository<T>.Current.Delete(entity);

    }

}

 

One important item in there is the IIdentifiable interface, I've seen some posts around either using Dynamic Linq or reflection to implement the GetById method but I prefer this. This won't work for all objects that dont't have an identity column, but for most of mine it's fine. This allows us something really cool, a kinda mix in. A conditional extension method on the repository class.

public interface IIdentifiable

{

    int Id

    {

        get;

    }

}


public static T GetById<T>(this IRepository<T> repository, int id) where T : class, IIdentifiable

{

    if(repository == null)

        throw new ArgumentNullException("repository");

 

    return repository.Where(i => i.Id == id).FirstOrDefault();

}


public partial class Product : ActiveRecordBase<Product>, IIdentifiable

{

    public static IQueryable<Product> GetOnSaleProducts()

    {

        return GetAll().Where(p => p.IsOnSale);

    }

}

 

Next post I'll set up a unit test base class for the in-memory tests and managing our unit of work.

Page 1 of 3123>

Professional Windows App Development