Archive for January, 2010

Implementing the Repository Pattern with LLBLGEN

This post has been sitting in draft for a while but finally managed to get round to completing it. I started it back in 2009. Apologies for the delay :)

It was the start of 2009, and I was investigating ORM tools for a new project we were working on at Clyral. We had been using Linq 2 SQL as our core database access layer for some time but felt we had outgrown it and were looking for something a bit more powerful and flexible. It didn’t take long for us to discover LLBLGEN. Whilst not the most intuitive acronym for an O/R mapping framework, LLBLGEN (Lower Level Business logic Layer Generator) impressed the team from the outset. After downloading the demo version and playing around with it on a test project we committed to purchasing it and since then haven’t looked back.

We started off using the Self Servicing model of the framework as it was earmarked for beginners, in time though, we began to see that we would get more mileage using the adapter model and began using this model as the defacto standard for projects. It was at this point we began looking at ways to implement the repository pattern which simplifies the testing process and ensures the implementation (which is often technology specific) does not get mangled with the domain model. To achieve this we needed every entity to implement an interface (or contract if you will). The problem with this of course, is that in C# generic variance is not supported. This posed a bit of a problem because we still wanted the full representation of a given entity graph to be available using our defined interfaces. To get around this, we needed to update the LLBLGEN templates to allow us to inject our own custom implementation of collections which would match our interface definitions. I have provided a few example snippets to illustrate what I am talking about. Essentially we added properties which took a Todos collection (property of a TodoList entity) such as defined below:

public virtual EntityCollection<TodoEntity> Todos
{
	get
	{
		if(_todos==null)
		{
			_todos = new EntityCollection<TodoEntity>(EntityFactoryCache2.GetEntityFactory(typeof(TodoEntityFactory)));
			_todos.SetContainingEntityInfo(this, "Todolists");
		}
		return _todos;
	}
}

and added the code below to support out interface definition:

public EntityList<ITodoEntity, TodoEntity>  TodosCollection
{
	get
	{
		if (_TodosCollection == null)
		{
			_TodosCollection = new EntityList<ITodoEntity, TodoEntity>(this.Todos);
		}
		return _TodosCollection;
	}
}

private EntityList<ITodoEntity, TodoEntity>  _TodosCollection;

where “EntityList” is a custom wrapper we wrote to get around the generic variance issue (note that EntityList understands that a TodoEntity is an implementation of ITodoEntity). This allowed us to define our entity contracts as such:


    /// <summary>
    /// Interface for the entity 'TodoList'.
    /// </summary>
	public partial interface ITodoListEntity 
	{
		EntityList<ITodoEntity, TodoEntity>  TodosCollection {get;}		

	
		System.Int32 Id {get;set;}
		System.String Title {get;set;}
		System.String Description {get;set;}
		System.Int32 ProjectId {get;set;}
		System.Int16 Position {get;set;}
		System.Boolean Billable {get;set;}
		System.DateTime CreatedOn {get;set;}
		System.DateTime ModifiedOn {get;set;}
		System.String CreatedBy {get;set;}
		System.String ModifiedBy {get;set;}
		System.Guid CreatedUserId {get;set;}
		System.Guid ModifiedUserId {get;set;}
	}

As you can see, a standard was implemented where the original list’s name was simply extended with the word “Collection”. After modifying the adapter’s templates and generating our templates to create the entity contracts, everything fell into place and we had our repository pattern implemented. Our repository definitions ensured that only interfaces were passed round (of course implemented using LLBLGEN’s entities) which in turn ensured that our UI (or business logic) knew nothing about the underlying implementation. One benefit of doing this is that the chaps working on the UI never had to deal with the copious number of properties and methods that hang off an LLBLGEN entity by default. Of course, these properties and methods are useful in some cases and can still be used within the repository itself.

I have attached a zip file to this post with the implementation of the EntityList class as well as the templates that we modified and added to make this all happen. Let me know what you think, any comments or suggestions regarding the implementation are certainly welcome!

Rohland

Templates and supporting files