Posts Tagged ‘llblgen’

Workflow 4.0 – Custom activities not appearing in the VS2010 toolbox

I thought this particular issue warranted a blog post because it took me a good couple of hours to track down the problem. Essentially as the title suggests, my custom Workflow 4.0 activities were not appearing in the Workflow 4.0 toolbox on a few projects I am working on.

If I created a new Workflow 4.0 project in Visual Studio 2010, everything worked as it should. However, if I integrated Workflow 4.0 with an existing project I ran into problems. After numerous Google/Bing searches I found a few examples of forum/stackoverflow posts about the problem but usually in the VS2010 Beta context.

It tuned out that the problem in my case is that I had two projects in my solution where the project files (*.csproj) were in the same directory. VS2010 did not like that for some reason. After moving the two projects into separate folders, everything worked! Absolutely bizarre.

If you are interested, the reason I had two project files in a single directory was because it’s the default configuration when using LLBLGEN (adapter mode). It generates two projects, one database specific and the other generic. It is possible to get LLBLGEN to generate the projects in separate folders, you can find the instructions here.

Feel free to play the sad trombone if you wasted as much time as I did.

Cheers,
Roh

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