Well, after a little rest from the blog – work and family take their time too – I’m back stronger than ever to publish some more new techniques for your .NET applications.

This time we will create an object factory using Linq Expression Trees, adding to that the use of CustomAttributes. This will allow us to totally decouple the object factory from the objects it creates. This method will allow you even having the factory in a separate layer of your application that nobody should touch to create their own objects. You just need to define the new class and add the custom attribute. The factory will scan all creatable objects at initializacion without having to modify any of its code (you wouldn’t even need to have the source files and put it in a nuGet package).

As always, you can download the whole sample project using Git or in a simple .ZIP file. Please note that if you want to run it using an older version of Visual Studio (2012, 2013) you will need to change the Console.WriteLine statements in Program.cs as I’m using the new syntax in C# 6 to create the output texts (ain’t it cute?).

Download ZIP: https://bitbucket.org/joanvilarino/messagehandlersample/get/62edf410d1ae.zip
Clone Git repository: https://joanvilarino@bitbucket.org/joanvilarino/messagehandlersample.git


As those of you reading my previous articles already know, I always try to set up a utility scenario so you can see the technique applied to something similar to real life that you’ll likely find in your own projects.

The Message Manager

For today’s example we’ll guess we have to create a library that will receive messages from an external application in string format, and each message type has to be parsed differently because it has different fields and data. In all of the messages, we’ll stablish a field separator with the “|” (pipe) character. In the sample project we’ll create three different kind of messages:

  • The “TABLE” type message contains an Id, and a Name.
  • The “ARTICLE” type message contains a Code, a bool IsActive field and a Quantity.
  • The “CALENDAR” type message contains a Date and a Description.

As all of these are responses we’ll get from our imaginary external service, we’ll call them Responses, and every class parsing them (Response Handler) will generate a different kind of DTO (Data Transfer Object) with its needed properties.

Here goes DTOs

public class TableDTO
{
    public long Id { get; set; }
    public string Name { get; set; }
}
public class ArticleDTO
{
    public string Code { get; set; }
    public bool IsActive { get; set; }
    public decimal Quantity { get; set; }
}
public class CalendarDTO
{
    public DateTime Date { get; set; }
    public string Description { get; set; }
}

Response handlers

What I’ve called Response Handlers are classes that will parse the value string and get the information we need for our required DTO. We’ll make them all inherit from a common GenericResponse which at the same time will inherit from BaseResponse (we use this last to be able to use it without generics for a base type returned).

public abstract class BaseResponse
{
    public static char FieldSeparator = '|';

    protected string Value { get; set; }

    public BaseResponse(string value)
    {
        Value = value;
    }
}
public abstract class GenericResponse<T> : BaseResponse where T : class, new()
{
    public GenericResponse(string value) : base(value) { }

    public abstract T GetValue();
}

As you can see, the common feature is GetValue method from GenericResponse who will return the parsed DTO from the string containing the values and it’s common to all Response Handler classes.

Once we have all the base classes, we’ll create our Response Handler classes for every DTO type (I show you here only the first, as the rest are very similar changing only the DTO class, the mapping and the value passed to the attribute).

[HandlesResponseType("TABLE")]
public class TableResponse : GenericResponse<TableDTO>
{
    public TableResponse(string value) : base(value) { }

    public override TableDTO GetValue()
    {
        try
        {
            var result = new TestDTO();
            var valueArray = this.Value.Split(FieldSeparator);
            result.Id = long.Parse(valueArray[1]);
            result.Name = valueArray[2];
            return result;
        }
        catch
        {
            throw new FormatException();
        }
    }
}

Here you must note that HandlesResponseType attribute that will be used by the factory later to know what classes can be created. This attribute has the information to make the factory know in first place that this class can be created and, in second place, what kind of value string is able to parse.

Creating our Object Factory

The factory pattern is well known in the development world. It’s used to decouple the object creation logic from the application logic using a class (normally a static or singleton one) that will “craft” our objects already populated with the data needed, more or less like this:

var myNewObj = ResponseFactory.Create(params);

Many times, the factory will make straight new of the classes it needs using a switch or if-elseif block that chooses the class to instantiate. The problem with this approach is that we are tying or coupling the classes to the factory at compile time, and adding new supported classes would require modifying the factory.

To avoid that problem and achieve a totally decoupled factory, we will use a base class known by the factory, and we’ll make our classes inherit from it. Though this is not mandatory, we will normally use a factory to create related objects, so it’s a good approach to use inheritance and polimorphism because they’re brutal tools when designing software. This second way to create the factory will use Reflection to get the class type and will call Activator.CreateInstance to instantiate it. This can save us from class coupling, but if we have to create lots of objects (thousands or hundreds of thousands) Activator is pretty slow because it has to read the class metadata everytime we call Activate.

Expression Trees to the rescue

To avoid that speed problems that come with Activator, a very common (and advanced) technique is using Linq Expression Trees from the System.Linq.Expressions library to generate data that represents code, data you can modify and compile to get a delegate that will make what we need at runtime, instead of doing it at compilation time. This totally decouples the factory from the classes it creates.

Our factory will use this method to build “activator” delegates for the class we want, and we’ll keep that activators in a cache once they’re already compiled at start up, to use them to create objects with lightning speed, many times the speed of Activator, only a little slower than using Emit, another technique that someday we’ll talk about, but Emit implies a little knowledge of IL (yes, that monster that looks like assembler that crawls under .NET and goes out every night to create nightmares and eat some developer’s children! 😉 ).

Building the activator cache dictionary

On application startup, the factory’s static constructor will scan the ExecutingAssembly for the types we marked with our custom attribute HandlesResponseTypeAttribute (you can change the code to allow loading of external assemblies, even from their .dll files), will build an activator delegate for each of them and add it to the cache dictionary using the ResponseType field from the attribute as key, so it can be retrieved later knowing the type of response we need to parse.

static ResponseFactory()
{
    // Build the cache dictionary that will contain all the compiled activators
    _expressionTreeActivatorsCache = Assembly.GetExecutingAssembly().GetTypes()
        .Where(t => t.GetCustomAttributes<HandlesResponseTypeAttribute>().Any())
        .Select(type => {
            var handlesResponseTypeAttr = type.GetCustomAttribute<HandlesResponseTypeAttribute>().ResponseType;
            return new { responseType = handlesResponseTypeAttr, activator = BuildExpressionTreeActivatorFor(type) };
        })
        .ToDictionary(o => o.responseType, o => o.activator);
}

Building the activator

The Expression Tree generation method takes all the class’ constructor parameters and builds expressions for them like this:

private static T GetExpressionTreeActivatorFromCtor<T>(ConstructorInfo ctor) where T : class
{
     // Get the constructor's parameters
     var ctorParams = ctor.GetParameters();
     var paramExp = Expression.Parameter(typeof(object[]), "args");
     // Create a list expression trees for each of the parameters
     var expList = ctorParams.Select((ctp, i) =>
         {
             var ctorType = ctp.ParameterType;
             var argExp = Expression.ArrayIndex(paramExp, Expression.Constant(i));
             var argExpConverted = Expression.Convert(argExp, ctorType);
             return argExpConverted;
         });
     // Build the Expression
     var newExp = Expression.New(ctor, expList);
     // Compile it to get the activator
     return Expression.Lambda<T>(newExp, paramExp).Compile();
}

If you noticed, all the parameter expressions are stacked in a “parent” expression that contains our class’ constructor and the generated list:

var newExp = Expression.New(ctor, expList);

Once we have the expression we return the compiled activator delegate using Expression.Lambda like this:

return Expression.Lambda<T>(newExp, paramExp).Compile();

This turns the “data” from expression to compiled code at runtime. Knowing that expresions generation is expensive in resources, we save it in a dictonary so we don’t need to re-generate it everytime we need to instantiate a new object (that would be even more expensive than using Activator).

Though I could’ve used a tailored delegate for our base class (using string) as single parameter for the constructor for all our objects, I used a method I had from previous projects that will allow constructing any kind of object by scanning all the constructor’s parameters.

Instantiating objects

When we call Create from our application passing the string we’ve received from our imaginary external service, the factory will read the “response type” (first field of the string with the “|” separator) and will use it to find its activator in our cache dictionary where we previously stored it already compiled, instantiates the new object and returns it.

public static BaseResponse Create(string value)
{
    if (string.IsNullOrWhiteSpace(value)) throw new ArgumentException();
    // Get the response type
    var responseType = value.Split(BaseResponse.FieldSeparator)[0];
    // Get the activator delegate to create that object from cache
    var activator = GetActivatorFor(responseType);
    // Instantiate the object calling the activator with the value parameter
    var result = activator(value);

    return (BaseResponse)result;
}

Cool! but… this works? Well, it’s supposed…

Ok, we have all the architecture done, so we’re gonna test it at the Main method of our Program.cs to see how it runs…

static void Main(string[] args)
{

    var responseList = new List<string>
    {
        "TABLE|10|Item Id 10",
        "ARTICLE|ABCCDEE|true|2,5",
        "TABLE|15|Item Id 15",
        "TABLE|20|Item Id 20",
        "CALENDAR|01/05/2016 14:00|Meeting",
        "ARTICLE|9388d99|false|0,20",
        "CALENDAR|06/02/2017 17:00|Buy more Redbull"
    };

    Console.WriteLine("Processing list: ");
    Console.WriteLine();


    var responses = responseList.Select(responseString => ResponseFactory.Create(responseString));

    // If you want to process the responses
    ProcessTableResponses(responses.OfType<TableResponse>());
    ProcessArticleResponses(responses.OfType<ArticleResponse>());
    ProcessCalendarResponses(responses.OfType<CalendarResponse>());

    // If you just want the DTOs
    var tableDtos = responses.OfType<TableResponse>().Select(r => r.GetValue());
    var articleDtos = responses.OfType<articleResponse>().Select(r => r.GetValue());
    var calendarDtos = responses.OfType<CalendarResponse>().Select(r => r.GetValue());

    Console.WriteLine();
    Console.Write("Press any key to exit...");
    Console.ReadKey();
}

As you see, we’ve created a list of string simulating what we could be receiving from our imaginary external service with records of the three types all mixed together. After that, using the factory, we get a list of Response Handler objects.

The factory will take care of selecting the right class for every message type as we saw before, and the result will be a IEnumerable in responses with the different Response Handler object in a polimorphic list (all of them inherit from ResponseBase, right?).

Right away to test the process we call some private methods by filtering Response Handlers of each type using .OfType (god bless this method) so we can print out the different type of data to the console.

If you just want to get the DTOs, right after that there are 3 lines of code with tableDtos, articleDtos and thirdDtos using the Response Handler’s method GetValue, thought they’re not really used in this sample. They’re there just for demonstration purposes.

Thank you!

Well… today’s article has been a little thick, but you have to reckon this is a complicated senario and I’ve trid to keep it as simple as possible. If you have questions about it, here I am to answer all of them the best way I can.

As always, you can download the whole sample project using Git or in a simple .ZIP file. Please note that if you want to run it using an older version of Visual Studio (2012, 2013) you will need to change the Console.WriteLine statements in Program.cs as I’m using the new syntax in C# 6 to create the output texts (ain’t it cute?).

Download ZIP: https://bitbucket.org/joanvilarino/messagehandlersample/get/62edf410d1ae.zip
Clone Git repository: https://joanvilarino@bitbucket.org/joanvilarino/messagehandlersample.git

Cheers and peace y’all!

Follow me

Joan Vilariño

Senior .NET Developer at Ohpen
Developer for more than 25 years and IT, gadget, mobile and electronics enthusiast working and publishing from Barcelona.
Follow me