.Net Development

Implementing Find and Replace for Expression trees

2011-09-28T12:12:00.000-07:00

UPDATE September 2011

The code described below in now available from NuGet that installs a single file (ExpressionExtensions.cs) into your project.

In addition to search and replace, methods for expression composition (AND/OR) has been added.

Get it from NuGet…….PM> Install-Package ExpressionTools

The source is now hosted at GitHub

Introduction

Imagine that you are working with an Expression tree and you need to check
if the tree contains a certain Expression with certain property values.

What we basically would need to do is to visit every node(Expression) in the tree
and check to see if the Expression matches what we are searching for.

First of all we need a class that visits all the nodes in the tree.

The ExpressionVisitor

The ExpressionVisitor class that can be found in the MSDN documentation is sort of an
all purpose class when dealing with expressions.

It was originally written by Matt Warren (the father of Linq to Sql) and was first published
as part of his "Building an IQueryable Provider" series

The expression visitor was considered so essential for everyone working with expression trees,
so they finally included the source in the MSDN documentation.
The implementation is really quite simple. It takes care of visiting all the nodes in the tree as well as it takes care of rewriting the tree if we make any changes to it. Great stuff!!

So what we are aiming for here is some kind of method that returns a list of expressions
that matches any predicate defined for the expression (sub)tree.

Implementing Find

Extension methods are a great way of adding new features to existing types and in this case
we want to extend the Expression class.

/// <summary>
/// Returns a list of <typeparamref name="TExpression"/> instances 
/// that matches the <paramref name="predicate"/>.
/// </summary>
/// <typeparam name="TExpression">The type of <see cref="Expression"/> 
/// to search for.</typeparam>
/// <param name="expression">The <see cref="Expression"/> that represents the sub tree for which to start searching.</param>
/// <param name="predicate">The <see cref="Func{T,TResult}"/> used to filter the result</param>
/// <returns>A list of <see cref="Expression"/> instances that matches the given predicate.</returns>
public static IEnumerable<TExpression> Find<TExpression>(this Expression expression, Func<TExpression, bool> predicate) where TExpression : Expression
{
    var finder = new ExpressionFinder<TExpression>();
    return finder.Find(expression, predicate);
}

Given the following expression:

Expression<Func<string, bool>> expression = (s) => s.Length == 5;

we can do a search in the expression tree by doing:

var binaryExpressions = expression.Find<BinaryExpression>(b => true);

or vi could search for ConstantExpression like this:

var constantExpressions = expression.Find<ConstantExpression>(c => (int)c.Value == 5);

A top-down search is performed in the sub tree that the target expression represents,
meaning that we can choose to investigate the whole tree or just individual sub trees.

The ExpressionFinder

This is a very simple class that override the Visit method that is called for every node in the expression tree.

If the expression being visited matches the given predicate, we add it to the list of matching expressions.

/// <summary>
/// A class used to search for <see cref="Expression"/> instances. 
/// </summary>
/// <typeparam name="TExpression">The type of <see cref="Expression"/> to search for.</typeparam>
public class ExpressionFinder<TExpression> : ExpressionVisitor where TExpression : Expression
{
    private readonly IList<TExpression> _result = new List<TExpression>();
    private Func<TExpression, bool> _predicate;

    /// <summary>
    /// Returns a list of <typeparamref name="TExpression"/> instances that matches the <paramref name="predicate"/>.
    /// </summary>
    /// <param name="expression">The <see cref="Expression"/> that represents the sub tree for which to start searching.</param>
    /// <param name="predicate">The <see cref="Func{T,TResult}"/> used to filter the result</param>
    /// <returns>A list of <see cref="Expression"/> instances that matches the given predicate.</returns>
    public IEnumerable<TExpression> Find(Expression expression, Func<TExpression, bool> predicate)
    {
        _result.Clear();
        _predicate = predicate;
        Visit(expression);
        return _result;
    }

    /// <summary>
    /// Visits each node of the <see cref="Expression"/> tree checks 
    /// if the current expression matches the predicate.         
    /// </summary>
    /// <param name="expression">The <see cref="Expression"/> currently being visited.</param>
    /// <returns><see cref="Expression"/></returns>
    protected override Expression Visit(Expression expression)
    {                        
        if (expression != null && expression is TExpression)
        {
            if (_predicate((TExpression)expression))
                _result.Add((TExpression)expression);
        }

        return base.Visit(expression);
    }
}

Implementing Replace

In addition to being able to search for expressions it would also be nice if we could do a simple replace using a similar syntax.

Another extension method is called for:

/// <summary>
/// Searches for expressions using the given <paramref name="predicate"/> and replaces matches with 
/// the result from the <paramref name="replaceWith"/> delegate.
/// </summary>
/// <typeparam name="TExpression">The type of <see cref="Expression"/> to search for.</typeparam>
/// <param name="expression">The <see cref="Expression"/> that represents the sub tree 
/// for which to start searching.</param>
/// <param name="predicate">The <see cref="Func{T,TResult}"/> used to filter the result</param>
/// <param name="replaceWith">The <see cref="Func{T,TResult}"/> used to specify the replacement expression.</param>
/// <returns>The modified <see cref="Expression"/> tree.</returns>
public static Expression Replace<TExpression>(this Expression expression, Func<TExpression, bool> predicate, Func<TExpression,Expression> replaceWith) where TExpression : Expression
{
    var replacer = new ExpressionReplacer<TExpression>();
    return replacer.Replace(expression, predicate, replaceWith);
}

We might think of the Replace method as an ad-hoc alternative to modifying the expression tree using an ExpressionVisitor derivate.

Given the following expression:

Expression<Func<string, bool>> expression = (s) => s.Length == 5;

we want to modify the expression tree by replacing the BinaryExpression(Equal) with a BinaryExpression(NotEqual).

This can now be achieved very easily by doing:

var modifiedExpression = expression.Replace<BinaryExpression>(b => true, 
    (b) => Expression.NotEqual(b.Left, b.Right));

The ExpressionReplacer

Similar to the ExpressionFinder it filter outs the target expressions, but instead of returning the matching expressions, it replaces the
matching expression with whatever the Func<TExpression,Expression> delegate returns.

One thing to notice here is that matching expression is passed to the replaceWith delegate.

/// <summary>
/// A class that is capable of doing a find and replace in an <see cref="Expression"/> tree.
/// </summary>
/// <typeparam name="TExpression">The type of <see cref="Expression"/> to find and replace.</typeparam>
public class ExpressionReplacer<TExpression> : ExpressionVisitor where TExpression : Expression
{
    
    private Func<TExpression, Expression> _replaceWith;
    private Func<TExpression, bool> _predicate;
    
    
    /// <summary>
    /// Searches for expressions using the given <paramref name="predicate"/> and 
    /// replaces matches with the result from the <paramref name="replaceWith"/> delegate.          
    /// </summary>
    /// <param name="expression">The <see cref="Expression"/> that 
    /// represents the sub tree for which to start searching.</param>
    /// <param name="predicate">The <see cref="Func{T,TResult}"/> used to filter the result</param>
    /// <param name="replaceWith">The <see cref="Func{T,TResult}"/> 
    /// used to specify the replacement expression.</param>
    /// <returns>The modified <see cref="Expression"/> tree.</returns>
    public Expression Replace(Expression expression, Func<TExpression, bool> predicate, 
        Func<TExpression, Expression> replaceWith)
    {
        _replaceWith = replaceWith;
        _predicate = predicate;
        return Visit(expression);
    }

    /// <summary>
    /// Visits each node of the <see cref="Expression"/> tree checks 
    /// if the current expression matches the predicate. If a match is found 
    /// the expression will be replaced.        
    /// </summary>
    /// <param name="expression">The <see cref="Expression"/> currently being visited.</param>
    /// <returns><see cref="Expression"/></returns>        
    protected override Expression Visit(Expression expression)
    {
        if (expression != null && expression is TExpression)
        {
            if (_predicate((TExpression)expression))
                return _replaceWith((TExpression)expression);
        }
        return base.Visit(expression);
    }
}

Enjoy!!!

Spellchecking in Visual Studio 2010

2011-09-06T07:55:00.001-07:00

Visual Studio 2010 has no built in support for spell checking, but there is an extension available that fixes this.

This amazing extension written by Roman Golovin and Michael Lehenl checks the spelling in your code comments as well as in html files.

As I have understood it takes advantage of the spell checking support in WPF and uses this functionality to implement the extension.

This all works fine if you’re located in the US or any other region that has a supported language.

The extension sets up the language based on the locale on your machine so if you’re outside one of English speaking regions, you will not be able to do spell checking in English.

But there is a way around this.

The code for this extension is available from GitHub and we only need to make one tiny little change in the source code to make it work.

Here is what to do.

Download the code from GitHub and locate the SpellingTagger class.

In the CheckSpellings method we need to add one line of code to make it default to “en"-US”.

     TextBox textBox = new TextBox();

    textBox.SpellCheck.IsEnabled = true;

    //Added to force english US language 

    textBox.Language = XmlLanguage.GetLanguage("en-US");

Compile the solution and install the extension by executing the SpellChecker.vsix file located in the Bin folder.

Now we can all have spell checking in Visual Studio 2010

Enjoy!!!

Using ORDERBY in derived tables

2011-08-17T00:11:00.001-07:00

In Microsoft SQL Server you are not permitted to use ORDERBY in a derived table unless you also provide a TOP(n) constraint.

Meaning that the following SQL is invalid

 SELECT * FROM (SELECT EmployeeID FROM Employees ORDER BY EmployeeID DESC) AS e
 

This will throw an exception from SQL Server

 The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions, unless TOP or FOR XML is also specified.
 

Based on the error message it is pretty obvious how to fix this.

 SELECT * FROM (SELECT TOP 5 EmployeeID FROM Employees ORDER BY EmployeeID DESC) AS e
 

Now the query runs just fine and just top make sure that the sorting actually works we can return the result bottom-up.

EmployeeID
-----------
10
9
8
7
6

(5 row(s) affected)

But what if we want to return all rows and still apply sorting?

Many forum posts suggests the following approach.

 SELECT * FROM (SELECT TOP 100 PERCENT EmployeeID FROM Employees ORDER BY EmployeeID DESC) AS e
 

The query still executes but the sorting is now completely omitted.

EmployeeID
-----------
10
3
4
8
1
2
6
7
5
9

The the solution to this is to provide a number to the TOP (N) clause that represents all the rows from the table.

The argument is a BIGINT and the highest possible value is 9223372036854775807.

Now if we change the query into this:

 SELECT * FROM (SELECT TOP 9223372036854775807 EmployeeID FROM Employees ORDER BY EmployeeID DESC) AS e
 

We can now see that the result comes back as expected sorted by EmployeeID.

EmployeeID
-----------
10
9
8
7
6
5
4
3
2
1

IL Merge and the 4.0 runtime

2011-01-13T05:34:00.001-08:00

If you are trying to ILMerge 4.0 assemblies make sure that you do the following:

Do NOT specify the /targetplatform:v4 as a command line parameter to ILMerge.exe

Create a file called ILMerge.exe.config and enter the following lines

<?xml version ="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<requiredRuntime safemode="true" imageVersion="v4.0.30319" version="v4.0.30319"/>
</startup>
</configuration>

That’s it!!!

ServiceLocator vs Dependency Injection

2010-09-22T04:22:00.001-07:00

During the past weeks I have been trying to figure out if I should go with the DI(Dependency Injection) pattern or the SL (Service Locator) pattern.
I assume here that the reader know the difference between the two.

I have been using the SL pattern for years know and it has proved to be very valuable.

But guess what? Now they tell me that it is considered an anti-pattern. Have a look here

What really bugs me is that all DI examples including the example from Mark Seemann, are so naive and simple.

Sure if you have InterfaceA and InterfaceB, you can live with passing an implementation of InterfaceB to the constructor of ClassA.

But graphs usually gets a little more complex that and if we follow the Soc principle, we might end up with a lot of dependencies in order for ClassA to actually do its magic.

The result of this is that the consumer of ClassA must manually wire up a dependency map before calling the constructor passing the root dependencies for ClassA.

To illustrate this we are going to use Mark’s example.

    public interface IOrderProcessor

        void Process(Order order);

    public class OrderProcessor

        private IOrderValidator _orderValidator;

        public OrderProcessor(IOrderValidator orderValidator)

            _orderValidator = orderValidator;

In order to use the order processor class we need to do the following:

OrderProcessor orderProcessor = new OrderProcessor(new OrderValidator());

That does not look to bad at all.

The OrderProcessor clearly states that it has a dependency upon an IOrderValidator implementation.

The question is… Do I really need to know about this dependencies? Let that rest for a minute while we expand the example.

Lets just quickly review the example from Mark.

public void Process(Order order)

    var validator = Locator.Resolve<IOrderValidator>();

    if (validator.Validate(order))

        var collector = Locator.Resolve<IOrderCollector>();

        collector.Collect(order);

        var shipper = Locator.Resolve<IOrderShipper>();

        shipper.Ship(order);

He only shows the SL variant of the example and I can’t help but wonder why?

Anyway, we see from the implementation that two more dependencies have been added to the OrderProcessor.

An interesting observation here is that the dependencies are only needed if the order is valid…….

But let’s stick with the DI approach and then we must add two more parameters to the OrderProcessor class.

    public class OrderProcessor

        private IOrderValidator _orderValidator;

        public OrderProcessor(IOrderValidator orderValidator, IOrderCollector orderCollector, IOrderShipper orderShipper)

            _orderValidator = orderValidator;

To use the OrderProcessor we now need to do this:

OrderProcessor orderProcessor = new OrderProcessor(new OrderValidator(), new OrderCollector(), new OrderShipper());

In addition to introducing a breaking change this also starts to look a little bit messy, wouldn’t you say?

We can also see here that we create OrderCollectior and OrderShipper instances regardless of the result from validator.Validate(order).

Lets take this even further by adding some logging capabilities.

All classes should have logging enabled and that means even more breaking changes.

ILogger logger = new Logger();
OrderProcessor orderProcessor = new OrderProcessor(new OrderValidator(logger), new OrderCollector(logger), new OrderShipper(logger));

I don’t know about you, but to me this starts to look a little complicated.

We might think of a solution where we let the OrderProcessor class create its own Logger, but that would be hiding a dependency, right?

Let’s get back to the question ..”Do I really need to know about this dependencies?”

I tell you what.. I just need to process orders and don’t really care that much how much magic is needed to actually do that.

If we review the actual contract (IOrderProcessor) involved to process orders it does not say anything about collectors and shippers.

So why should I care?

Do I really need to inject an IEngine instance before I can drive?

Yes, I would have to if I was the constructor of the car, but in this case I am just the consumer, see?

Remember Cole Trickle (Tom Cruise) from “Days of Thunder” .. (Yes, I’m actually that old)

"They told me to get in the car and drive and I could drive......but I don't know much about cars, o.k?!

What if the engine suddenly got equipped with a turbo?

So what? I DON’T CARE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I just want to drive!!

To solve this nightmare of manual wiring we can use an Ioc container.

Given that the container is configured it will happily resolve all dependencies for us.

The configuration of the container remains pretty much the same whether we use DI or SL so that is not an argument.

I feel that DI is somewhat of a “all or nothing” solution.

In order for the container to resolve our dependencies we must use this pattern from the get go. Otherwise we are faced with manual dependency injection which I think we all can agree can become pretty messy.

Feel free to leave a comment, I would love to hear your opinion

Regards

Bernhard Richter

Merging(ILMerge) assemblies targeting the .Net Runtime v4.0

2010-07-16T05:44:00.001-07:00

Today I started the process of upgrading a lot of projects to Visual Studio 2010 and at the same time I set the target framework to 4.0.

Everything went relatively smooth except for the some projects where we have modified the msbuild file to include a call to ILMerge.

First it complained it could not resolve the reference to System.Core

Unresolved assembly reference not allowed: System.Core.

As it turned out I needed to tell ILMerge what framework version to use and where it is located.

Mike Barnet has mentioned this at Microsoft Research and the solution is to add a command line parameter like this: /targetplatform:v4,<path to your v4 framework directory>

So where is the v4 framework directory?

It is located in “C:\Windows\Microsoft.NET\Framework\v4.0.30319” provided you have a default installation.

So I added the command line parameter like this

/targetplatform:v4“C:\Windows\Microsoft.NET\Framework\v4.0.30319”

Make sure that you don’t have a space between the version and the path. It actually caused a stack overflow on my machine :)

Anyway this worked very well and no more complaints about unresolved assemblies.

That was until I tried to merge an assembly that referenced the PresentationCore.dll.

Unresolved assembly reference..again.

What now?

After some investigation I found out that PresentationCore.dll is not located in “C:\Windows\Microsoft.NET\Framework\v4.0.30319”, but in a WPF subfolder.

Aha, that must be it.

The trick here is that the path to the framework should be this
“C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0”

This directory contains all the framework assemblies including PresentationCore.dll

So I changed the command line parameter to

/targetplatform:v4“C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0”

Suddenly all merging of assemblies succeeded.

Adding mocking features to LinFu.Ioc

2010-07-15T03:51:00.001-07:00

This post will show how to integrate a mocking library with the service container available in the LinFu framework.
We are going to kick this off by showing an example where the use of mock objects might be useful.

Imagine that we have two interfaces like the ones below.

public interface IServiceA
{
    int CalculateSomething();
}


public interface IServiceB
{
    int CalculateSomethingElse();
}

If we take a look at the implementation below we can see that ServiceA has a dependency to an IServiceB implementation.

public class ServiceA : IServiceA
{
    private IServiceB _serviceB;
    public ServiceA(IServiceB serviceB) 
    {
        _serviceB = serviceB;
    }

    public int CalculateSomething()
    {
        //Do something clever here....
        _serviceA.CalculateSomethingElse();
        //Do even more intelligent suff...
        return 42;
    }
}

It should be noted that dependency injection can be done in a variety of ways, but here it is done using constructor injection.

This means that when we request an instance of IServiceA the service container will also resolve the IServiceB implementation needed in the ServiceA constructor.

When writing our unit test for ServiceA, we might not be interested in whatever IServiceB does or even worse, it could represents a remote call not accessible to us when testing IServiceA. So we need to replace the default IServiceB implementation with a dummy implementation.

It is obvious how this can be done the manual way since this is such a naive example, but setting up mocking objects can be pretty complex if we need to install multiple objects.

It can also be the case that the dependency is created internally so that we do not have an easy way of replacing the implementation with a mocking instance.

So we need a way to tell the service container that whenever a request for a IServiceB instance is executed, it should return a mock instance.

It should also be noted here that I have used the Moq framework, but I guess this could very easily be adapted to other mocking frameworks as well.

Anyway, this is what I came up with:

ServiceContainer.StartMocking<IServiceB>();
var serviceA = ServiceContainer.GetService<IServiceA>();
var result = serviceA.CalculateSomething();
Assert.AreEqual(42,result);

We can see that creating a mock and configuring the service container is pretty simple.

ServiceContainer.StartMocking<IServiceB>();

This is all that we really need to do in order to replace the actual IServiceB implementation.

Buy what about those expectations you say?….

As it turns out the StartMocking method return a Mock<T> instance so that we can configure the mocking instance.

var mock =  ServiceContainer.StartMocking<IServiceB>();
mock.Expect(s => s.CalculateSomethingElse()).Returns(1);

So how is this actually possible? Well, we need to take a deeper look into LinFu.Ioc to answer that.

LinFu.Ioc actually offers several ways of hooking into the process of resolving service types and one is by implementing the IPreProcessor interface.

An IPreProcessor implementation allows us to inspects the service request and optionally replace its default factory.

/// <summary>
/// Inspects the requested service type and returns a mocked service instance if 
/// mocking has been enabled for the service type.     
/// </summary>
/// <seealso cref="ContainerExtensions"/>
public class MockPreprocessor : IPreProcessor
{
    private readonly IList<MockServiceInfo> _mockedServices;

    /// <summary>
    /// Initializes a new instance of the <see cref="MockPreprocessor"/>
    /// </summary>
    /// <param name="mockedServices"></param>
    public MockPreprocessor(IList<MockServiceInfo> mockedServices)
    {
        _mockedServices = mockedServices;
    }

    /// <summary>
    /// Inspects the service request and return a mocked service if available.
    /// </summary>        
    public void Preprocess(IServiceRequest request)
    {
        var serviceName = string.IsNullOrEmpty(request.ServiceName) ? null : request.ServiceName;
        
        var mockedServiceInfo =
            _mockedServices.Where(
                ms => ms.ServiceType == request.ServiceType && ms.ServiceName == serviceName).FirstOrDefault
                ();
        
        if (mockedServiceInfo != null)            
            request.ActualFactory = new FunctorFactory(r => mockedServiceInfo.Mock.Object);
    }
}

The MockPreProcessor takes a list of MockServiceInfo instances that basically tells the preprocessor what types for which to return mock objects.

/// <summary>
/// Contains details about the service type being mocked
/// </summary>
public class MockServiceInfo
{
    /// <summary>
    /// Gets or sets the <see cref="Mock"/> instance.
    /// </summary>
    public Mock Mock { get; set; }
    
    /// <summary>
    /// Gets or sets the service type being mocked.
    /// </summary>
    public Type ServiceType { get; set; }
            
    /// <summary>
    /// Gets or sets the name of the service being mocked.
    /// </summary>
    public string ServiceName { get; set; }
}

Now that we have all the basic infrastructure in place, we need some extensions methods that defines the API for the Moq integration.

/// <summary>
/// Contains extensions methods to integrate the Moq mocking library with the LinFu.Ioc framework.
/// </summary>
/// <seealso cref="http://code.google.com/p/moq/"/>
public static class ContainerExtensions
{
    private static readonly IList<MockServiceInfo> _mockedServices = new List<MockServiceInfo>();

    /// <summary>
    /// Creates a new <see cref="Mock{T}"/> instance and instructs the <see cref="IServiceContainer"/> 
    /// to return the <see cref="Mock.Object"/> instead of the actual service instance.
    /// </summary>
    /// <typeparam name="T">The type of service being mocked.</typeparam>
    /// <param name="serviceContainer">The <see cref="IServiceContainer"/> that will handle the mocked service request.</param>
    /// <returns><see cref="Mock{T}"/></returns>
    public static Mock<T> StartMocking<T>(this IServiceContainer serviceContainer) where T:class
    {            
        return StartMocking<T>(serviceContainer, null);            
    }

    /// <summary>
    /// Creates a new <see cref="Mock{T}"/> instance and instructs the <see cref="IServiceContainer"/> 
    /// to return the <see cref="Mock.Object"/> instead of the actual service instance.
    /// </summary>
    /// <typeparam name="T">The type of service being mocked.</typeparam>
    /// <param name="serviceContainer">The <see cref="IServiceContainer"/> responsible for creating the mocked service.</param>
    /// <param name="serviceName">The name of the service being mocked.</param>
    /// <returns><see cref="Mock{T}"/></returns>
    public static Mock<T> StartMocking<T>(this IServiceContainer serviceContainer, string serviceName) where T:class
    {
        InstallMockPreProcessor(serviceContainer);

        return CreateMock<T>(serviceName);
    }

    private static Mock<T> CreateMock<T>(string serviceName) where T:class
    {                        
        var mock = new Mock<T>();            
        var mockServiceInfo = new MockServiceInfo();
        mockServiceInfo.Mock = mock;
        mockServiceInfo.ServiceName = string.IsNullOrEmpty(serviceName) ? null : serviceName;
        mockServiceInfo.ServiceType = typeof (T);
        _mockedServices.Add(mockServiceInfo);
        return mock;
    }

    private static void InstallMockPreProcessor(IServiceContainer serviceContainer)
    {
        if (!serviceContainer.PreProcessors.Any(p => p.GetType() == typeof (MockPreprocessor)))
            serviceContainer.PreProcessors.Add(new MockPreprocessor(_mockedServices));
    }


    /// <summary>
    /// Stops mocking the requested service type.
    /// </summary>
    /// <typeparam name="T">The service type currently being mocked.</typeparam>
    /// <param name="serviceContainer">The <see cref="IServiceContainer"/> currenly responsible for creating the mocked service.</param>        
    public static void StopMocking<T>(this IServiceContainer serviceContainer) where T : class
    {
        StopMocking<T>(serviceContainer, null);
    }


    /// <summary>
    /// Stops mocking the requested service type.
    /// </summary>
    /// <typeparam name="T">The service type currently being mocked.</typeparam>
    /// <param name="serviceContainer">The <see cref="IServiceContainer"/> currenly responsible for creating the mocked service.</param>
    /// <param name="serviceName">The name of the service curretly being mocked.</param>
    public static void StopMocking<T>(this IServiceContainer serviceContainer, string serviceName) where T : class
    {
        serviceName = string.IsNullOrEmpty(serviceName) ? null : serviceName;
        var mockServiceInfo =
            _mockedServices.Where(ms => ms.ServiceType == typeof (T) && ms.ServiceName == serviceName).
                FirstOrDefault();

        if (mockServiceInfo != null)
            _mockedServices.Remove(mockServiceInfo);
    }

    /// <summary>
    /// Stops mocking all services.
    /// </summary>
    /// <param name="serviceContainer">The <see cref="IServiceContainer"/> responsible for creating mocked services.</param>
    public static void StopMocking(this IServiceContainer serviceContainer)
    {
        _mockedServices.Clear();
    }

}

There are also methods for actually stop mocking types in the service container and that might be useful if you have different needs in various tests targeting the same service container instance.

Download the source here.

Happy mocking!!!

Bringing new aspects to life using the LinFu framework

2010-04-30T10:36:00.001-07:00

Today we are going to see some examples of Aspect Oriented Programming(AOP) and see how that can help us perform tasks that we otherwise might be forced to hard wire into our source code.

AOP can be thought of as a way of bringing new aspects/behaviors/features into our application without changing the original implementation.

The title for this article may be a little over the top, but if you're new to AOP, it may bring some new aspects to your life as a developer :)

We are going take a look at some examples and finish up by creating a simple data access library.

But first things first

Inversion Of Control

Before we delve into the world of AOP I thought it might be a good idea to talk a little about Inversion Of Control (IOC).

Inversion Of Control (also referred to as Dependency Injection) as a way of separating the creation of objects from their actual use.

I think maybe the term "Inversion of Control" is enough to scare people away from this type of software development. If you are already in control, why would you invert it as the term implies?. What does that even mean?

Lets illustrate this with an example. Imagine that we have some calculator class that can add two numbers and return the result.

             
public class Calculator
{
    public int Add(int value1, int value2)
    {
        return value1 + value2;
    }
}

Using this class from the client code would look something like the following:

Calculator calculator = new Calculator();

var result = calculator.Add(2, 2);

While the code certainly works, it creates a direct dependency between the client code and the concrete Calculator class.
Let's try to make things a little better by creating an interface for the Calculator class to implement.

public interface ICalculator

{

int Add(int value1, int value2);

}

public class Calculator : ICalculator

{

public int Add(int value1, int value2)

{

return value1 + value2;

}

Now the client code would change to something like:

ICalculator calculator = new Calculator();

var result = calculator.Add(2, 2);

Now this is getting better by the minute, but we are still faced with the problem of how to create a Calculator instance without the dependency problem.
I can almost hear some of you wondering "Why don't he just use the Abstract Factory Pattern?"
And for those of you going "Abstract what?", lets go ahead and implement it for our naive little example.

First we need an abstract factory

public interface ICalculatorFactory

{

ICalculator CreateCalculator();

}

Then we need a concrete factory

public class CalculatorFactory : ICalculatorFactory
{
   public ICalculator CreateCalculator()
    {
       return new Calculator();
    }
}

As for the abstract product and concrete product, we already have those defined (ICalculator and Calculator).
The client code would now be changed to this:

ICalculatorFactory factory = new CalculatorFactory();

ICalculator calculator = factory.CreateCalculator();

var result = calculator.Add(2, 2);

Given that the CalculatorFactory class and the Calculator class is not contained in the same assembly, the client code does not longer need to know anything about the concrete Calculator class.

While this is a very naive example and does not fully show the power of the Abstract Factory Pattern, we still see that we need to do quite some work to create the abstractions we want.

In the world of IOC, we don’t really deal with abstract factories and all the plumbing needed.
We just rely on the service container to resolve our dependencies.

Using a service container we could instead just write:

serviceContainer.GetService<ICalculator>();

We have no factory classes to support this so how can the service container figure out the concrete type?

Introducing LinFu.Ioc

Several years ago I came across this article written by my good friend and colleague, Philip Laureano. It was this very article that really got me started on creating loosely coupled applications in the first place.

There are a vast of Ioc frameworks available including the relatively new Unity framework from Microsoft, but I have yet to see something that is so simple to use and understand.
As you will learn throughout this articles, I am not a big fan of XML configuration (or any configuration for that matter) and as you will see, configuring the LinFu service container takes only one single line of code.

serviceContainer.LoadFrom(AppDomain.CurrentDomain.BaseDirectory, "*.dll");

Now lets see what we need to do in order to have the container return an ICalculator instance.

[Implements(typeof(ICalculator))]

public class Calculator : ICalculator

{

public int Add(int value1, int value2)

{

return value1 + value2;

}

Notice the difference from our previous example?
The ImplementsAttribute tells the container that this is the concrete implementation to create when a request for an ICalculator instance is made.
I can only speak for my self here, but I find this a lot easier than learning how to configure this using some kind of XML format.
Besides from being incredible easy to use, it is also very very flexible.
If your not already familiar with LinFu.Ioc, I strongly recommend reading more about it here.

A word about project structure

When starting out to create a new library I always create at least three sub projects for the library. If we take the sample code for this article, this is how the solution is set up.

AopDemo	Contains the interfaces
AopDemo.Implementation	Contains the implementation of the interfaces
AopDemo.Tests	Contains the unit tests

The thing to notice here is that the client code, here represented by the unit tests, will never reference the assembly containing the implementation.

In fact, the implementation will never be referenced by any other assembly.

Aspect Oriented Programming

AOP can be thought of as a way of bringing new aspects/behaviors/features into our application without changing the original implementation.

Given the previous example, say that we wanted to do a Console.WriteLine every time we add two numbers. How could we do that without touching the actual Calculator class?

There are actually two ways of doing that and that is the "easy way" using a proxy and the rather more complicated approach that involves IL injection.

Both methods have their advantages and disadvantages, but the proxy approach most certainly have the advantage of being simple to implement.

So what we are going to to here is implement a proxy that adds our new aspect (Console.WriteLine) to the ICalculator implementation.

The Proxy

Now lets start off by looking at what a proxy actually is.
A proxy is something that sits between the caller and the actual implementation.

As we can see the proxy also implements the ICalculator interface and hence the caller is still obliviously happy since it does not really care about the actual implementation as long as it implements the expected interface.
In addition to forwarding method call from the caller to the actual implementation (Calculator), the proxy object also offers interception of the calls being made.

So what we need here is an interceptor that we can use to implement our simple logging mechanism.

Introducing LinFu.Proxy

The LinFu framework not only ships with an excellent IOC container, but it also contains a very flexible proxy library.

One thing that I really like about this library, is that it is built using the IOC principle/pattern which makes it easy if we need to handle corner case scenarios.

That is, however not within the scope of this article so we are going to get back to creating the interceptor we need to perform logging in the calculator.

public class CalculatorInterceptor : IInterceptor

{

public object Intercept(IInvocationInfo info)

{

Console.WriteLine("The Add method has been invoked");

return info.TargetMethod.Invoke(info.Target, info.Arguments);

}

The Intercept method is called whenever the client code calls a method through the proxy object.

The question now remains...How do we tell the service container to return a Calculator Proxy instead of the actual Calculator?

Again the flexibility in LinFu opens up for several ways of doing that and here is an very elegant approach I am almost certain you have never seen before.

Let's change the CalculatorInterceptor into the following:

[Intercepts(typeof(ICalculator))]

public class CalculatorInterceptor : IInterceptor

{

public object Intercept(IInvocationInfo info)

{

Console.WriteLine("The Add method has been invoked");

return info.TargetMethod.Invoke(info.Target, info.Arguments);

}

Notice the difference? Take a look at the Intercepts attribute.
This attribute actually tells the service container to create a proxy object and forward method calls to this class.

Believe it or not, we have actually added a new aspect to the calculator with just 9 lines of code (Counting the curly brackets).

How's that for easy of use and flexibility?

The only requirement for the CalculatorInterceptor is that it is located on disc when the container is configured.

This means that we can add tracing to an already deployed application just by doing a simple XCopy.

This is getting so good that I think we should spend a little time to take this to the next level.

Say now that we wanted to allow for multiple logging targets and not just a simple Console.WriteLine.

We could of course add each logging target to the CalculatorInterceptor, but lets make this a little more exciting.

We start of by abstracting the actual logging out of the CalculatorInterceptor by creating an ILogger interface.

public interface ILogger
{
    void Log(string message);
}

Then we are going to ever so slightly alter the CalculatorInterceptor class.

[Intercepts(typeof(ICalculator))]

public class CalculatorInterceptor : IInterceptor, IInitialize

{

private IEnumerable<ILogger> _loggers;

public object Intercept(IInvocationInfo info)

{

foreach (var logger in _loggers)

{

logger.Log("The Add method has been invoked");

}

return info.TargetMethod.Invoke(info.Target, info.Arguments);

}

public void Initialize(IServiceContainer source)

{

_loggers = source.GetServices<ILogger>();

}

What’s new here is that we have implemented the IInitialize interface that is used by the service container to expose itself to the services instances it creates.

We then use the container to retrieve all implementations of the ILogger interface and handles the logging of to each instance.

And as for the Console.WriteLine, it has been moved to an ILogger implementation.

[Implements(typeof(ILogger))]

public class ConsoleLogger : ILogger

{

public void Log(string message)

{

Console.WriteLine(message);

}

The beauty of this is that we can now create as many ILogger implementations as we want and they will all be invoked when the Add method is invoked.

Pretty cool, wouldn't you say?

From naiveness towards the real world

While this so far has shown how flexible the LinFu framerwork is, it still remains a fact that the calculator example is pretty naive.

Let's pick it up a notch and create something useful. Why don't we create a DBMS independent data access library with profiling capabilities?
That might sound like a daunting task, but thanks to LinFu, this practically becomes a breeze.

Let's boil this data access paradigm down to what is it that we really need?
We need some object that we can use to execute sql, right?

For me it sounds like a IDbCommand implementation should fit the picture just perfectly.
How do we get a IDbCommand implementation? Simple, we just hand it off to the container like this:

var dbCommand = ServiceContainer.GetService<IDbCommand>();

But wait a minute, how does the container know what implementation of IDbCommand to create?

The answer is that is does not so we need to teach the container how to create an IDbCommand instance.

The code below shows a rudimentary factory implementation.

[Factory(typeof(IDbCommand))]
public class DbCommandFactory : IFactory<IDbCommand>
{        
    public IDbCommand CreateInstance(IFactoryRequest request)
    {
        var connectionStringSettings = GetConnectionStringSetting(request.ServiceName);
        var providerFactory = CreateProviderFactory(connectionStringSettings);
        var connection = providerFactory.CreateConnection();
        connection.ConnectionString = connectionStringSettings.ConnectionString;
        connection.Open();
        return connection.CreateCommand();            
    }
 
    private static DbProviderFactory CreateProviderFactory(
        ConnectionStringSettings connectionStringSettings)
    {
        return DbProviderFactories
            .GetFactory(connectionStringSettings.ProviderName);
    }   
 
    private static ConnectionStringSettings GetConnectionStringSetting(string connectionName)
    {
        if (String.IsNullOrEmpty(connectionName))
            return ConfigurationManager.ConnectionStrings
                .Cast<ConnectionStringSettings>().Last();
        return
            ConfigurationManager.ConnectionStrings
            .Cast<ConnectionStringSettings>().Where(
                c => c.Name.EndsWith(connectionName)).FirstOrDefault();
    }
}

Luckily for us, most of the abstractions has already been done for us. We just need to hook up with the appropriate DbProviderFactory and we are pretty much good to go.

We can now go ahead and configure our connection in app/web config and that's all we really need to do. We can now get a ready and willing IDbCommand instance by doing:

var dbCommand = ServiceContainer.GetService<IDbCommand>();

Sweet, but didn't I promise profiling capabilities? Okay, let's spend another five minutes.

We start off by creating an interface for the profilers

public interface IDbProfiler
{
    void BeforeExecute(IDbCommand dbCommand, MethodInfo methodInfo, object[] arguments);
    void AfterExecute(IDbCommand dbCommand, MethodInfo methodInfo, object[] arguments);
}

Next we need an interceptor that intercepts calls made to the actual DbCommand.

[Intercepts(typeof(IDbCommand))]
public class DbCommandInterceptor : IInterceptor, IInitialize
{
    private IEnumerable<IDbProfiler> _profilers;
 
    public object Intercept(IInvocationInfo info)
    {
        foreach (var dbProfiler in _profilers)
            dbProfiler.BeforeExecute((IDbCommand) info.Target, 
                info.TargetMethod, info.Arguments);
 
        var returnValue =  info.TargetMethod.Invoke(info.Target, info.Arguments);
 
        foreach (var dbProfiler in _profilers)
            dbProfiler.AfterExecute((IDbCommand) info.Target, 
                info.TargetMethod, info.Arguments);
 
        return returnValue;
    }
 
    public void Initialize(IServiceContainer source)
    {
        _profilers = source.GetServices<IDbProfiler>().ToList();
    }
}

As we can see we are doing much of the same that with did with in the calculator example.

Now lets finish this off by creating a sample IDbCommand profiler.

[Implements(typeof(IDbProfiler))]
public class ConsoleDbProfiler : IDbProfiler
{
    private readonly Stopwatch _stopwatch = new Stopwatch();
 
    public void BeforeExecute(IDbCommand dbCommand, MethodInfo methodInfo, object[] arguments)
    {            
        if (ShouldProfile(methodInfo))
        {
            _stopwatch.Reset();
            _stopwatch.Start();
        }
    }
 
    public void AfterExecute(IDbCommand dbCommand, MethodInfo methodInfo, object[] arguments)
    {
        if (ShouldProfile(methodInfo))
        {            
            _stopwatch.Stop();                
            Console.WriteLine(string.Format("The command '{0}' executed in {1} milliseconds"
                , dbCommand.CommandText, _stopwatch.ElapsedMilliseconds));
 
        }
    }
 
    private static bool ShouldProfile(MethodInfo methodInfo)
    {
        var methodName = methodInfo.Name;
        return (methodName == "ExecuteReader"
                || methodName == "ExecuteNonQuery"
                || methodName == "ExecuteScalar");
 
    }
}

The fact is that we use a similar approach at work at it has proven invaluable to us when it comes to hunting down long running queries.

The following code shows the execution of the query:

var dbCommand = ServiceContainer.GetService<IDbCommand>();
dbCommand.CommandText = "SELECT * FROM Orders";
var reader = dbCommand.ExecuteReader(CommandBehavior.CloseConnection);

And in our debug output window we can now observe the following:

The command 'SELECT * FROM Orders' executed in 116 milliseconds

And that my friends, is how we add new aspects to even a sealed type. (Yes, the SqlDbCommand is actually sealed)

Please note that all exception handling has been omitted for the sake of brevity.

Conclusion

As we have seen, using the LinFu framework, taking the shift towards AOP is ridiculously simple to overcome.

We have seen how we can add new aspects to existing classes with out touching the original code and even implemented a simple data access library.

We can also draw the conclusion that AOP helps serving the Separation of Concerns principle as we don’t clutter our classes with aspects that is beyond their initial intent.

So the next time you create a new class, make sure you do so by implementing an interface.

You never know when new requirements (aspects) arrive.

Enjoy!!!!

Tracking changes made to POCO objects

2010-02-03T05:04:00.001-08:00

Imagine that we retrieve a list of POCO (Plain Old CLR Objects) and we find our self in need to track changes made to those objects.

To illustrate this we use a very simple example like the Customer class:

    public class Customer
    {
        public string CustomerID { get; set; }
    }

Standard CLR properties has no built-in support for interception so the preferred way of doing this is to implement the INotifyPropertyChanged interface.

This interface allows us to notify subscribers that the property has changed and its widely used when two-way data binding is required.

If we bind, say a textbox to a property that does not support change notification, we end up with a situation where changes made to the textbox is automatically reflected in the property, but not the other way around.

The data binding mechanism (WinForms and WPF), relies heavily on this interface to do its magic.

The example below shows our modified Customer object with support for change notification.

    public class Customer : INotifyPropertyChanged
    {
        private string _customerId;
 
        public string CustomerID
        {
            get { return _customerId; }
            set
            {
                _customerId = value;
                OnPropertyChanged("CustomerID");
            }
        }
 
        protected void OnPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
                PropertyChanged(this,new PropertyChangedEventArgs(propertyName));
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
    }

Although the interface is quite easy to implement it also results in a lot of tidious code for us to write. Every property setter need that call to OnPropertyChanged passing along the property name.

Sure we could create a base class that implemented this interface and by that simplify it to some extent, but that takes our classes away from the POCO principle.

AOP to the rescue

I'd say that we let our objects remain POCO objects and implement the INotifyPropertyChanged interface at runtime instead.

You might wonder how that can be done and there are actually two ways of achieving that.

We can find a lot of documentation on Aspect Oriented Programming that is more or less difficult to understand, but let us try to sum it up in one sentence.

AOP is about adding new aspects to an object without the object ever knowing about it.

The Aspect in our case is implementing the INotifyPropertyChanged interface so that changes made to the Customer object are intercepted by the caller.

And we want to do this at runtime.

There are actually two ways of doing that and we can either use a proxy to the actual customer object or we can use IL injection to modify the customer object so that it implements what we need, in this case the INotifyPropertyChanged interface.

Lets start of simple with the proxy approach.

The Proxy

A proxy is an object that sits between the caller and the actual target object.

The proxy class will at least implement the target interface, but can also implement additional interfaces which is the key to our solution.

Creating a proxy object can be done in two different ways:

Create a proxy by sub classing the target object.
This requires all members to be declared as virtual members so that they can be overridden in the proxy type.
Create a proxy that implements the same interface that the actual target object does.
This requires the members to be declared in an interface implemented by the target object.

We are going to stick to the second approach here as we will see later, provides us with a little more flexibility.

So we extract the interface from our Customer object.

    public interface ICustomer
    {
        string CustomerID { get; set; }
    }
 
    public class Customer : ICustomer
    {
        public string CustomerID { get; set; }
    }

Now the customer implements a contract that also can be implemented by our customer proxy type.

As mentioned before the proxy class can implement additional interfaces and that means that the proxy type can implement the INotifyPropertyChanged interface.

The figure below shows that the textbox now binds to the CustomerProxy and since it implements INotifyPropertyChanged, a two-way communication now exists between the
CustomerProxy and the textbox (client).

So any changes to the CustomerID exposed by the CustomerProxy will now be reflected in the textbox.

And this actually brings us to the downside of the proxy approach.
For all this to work, changes to the CustomerID (that we want to be reflected in the textbox), must be made through the CustomerProxy.

If we have some logic inside the Customer object that internally updates the CustomerID property, the changes are not reflected in the textbox.

Why? Simply because we are not invoking the Customer proxy that is resposible for the change notification.

In the case that the proxied objects contains logic that may present a problem if the code actually updates the properties.

IL Injection.

This approach takes you far beyond the topics you might encounter in your average "Teach yourself C# in 21 days" book.

What we are talking about here is modifying the Customer class in such a way that it implements the INotifyPropertyChanged interface.

The modification is done by injecting the IL code that normally would be the result of implementing the interface in the first place.

The injection can be done at runtime or after the assembly has been compiled.

We are going concentrate on runtime modification here and that involves the following steps.

1. Load the assembly from disc (not into the application domain)

2. Modify the assembly (IL injection)

3. Save the assembly back to disc or load it as an byte array into the application domain without touching the original assembly.

There is only one library that I know of that actually allows us to do this, and that is Mono.Cecil.

This is a very powerful library that pretty much lets us do whatever we want with our assembly.

An interesting problem with this approach is how to get access to the target assembly before it is loaded into the application domain.

As we already know, once an assembly is loaded into the application domain, there is not much we can do about that. It can not be unloaded nor modified.

So we need to catch it BEFORE Fusion resolves the assembly and loads it into the application domain.

Again this presents us with two possible solutions.

Make sure that Fusion is unable to resolve the assembly and handle the AppDomain.AssemblyResolve event.
This can be done by placing the assembly in a subfolder
Make sure that the assembly is not referenced directly
Load the assembly our self and make the necessary changes to it before it gets loaded into the application domain.

IMHO, depending on Fusion being unable to locate the assembly seems somewhat “hacky”.

If the assembly is not referenced by the application itself, it can be loaded dynamically by an Inversion of Control container and we can hook into the load process and do our magic before the container starts to register services from that assembly.

There is also another that presents a challenge when doing IL injection and that is how to enable debugging in our modified/weaved assemblies.

If we modify the IL, the symbol information (pdb) also needs to be updated. If we don’t handle that properly, we will not be able to set a breakpoint inside a class that at runtime has been modified.

Mono.Cecil provides some support here and from what I have tested so far, we should be able to actually debug weaved assemblies.

Conclusion

As we can see there are many decisions that needs to be made as to how we are going to inject new behavior into our objects and I would say it depends a lot of what kind of behavior we want to add.

Initially I wanted to create some kind of state/change tracker that hooks up the PropertyChanged event and keeps track of changes made to an object graph.

My gut feeling here is to go with the Proxy implementation as it allows us to keep everything i C# (No IL injection) and it allows proxies to be installed in a lazy fashion as we navigate down the object graph.

It is also somewhat simpler to add support for new interfaces, for example the IDataErrorInfo interface if we should want to give some visual feedback when validation errors occur.

CoreEx.Common.Validation

2009-09-11T00:49:00.001-07:00

CoreEx.Common.Validation

When working with objects we often find the need to validate their contents before e.g. persisting them to a data store.

I have been putting this off for a long time now and I decided it was time to take a look at the options available.

Before we start lets define some requirements of the validation library.

Objects should be validated without the need to reference the validation library itself.

It must be possible to configure validation without the use of XML.

It must be possible to add new validation rules to an object without the need to recompile.

It should be possible to validate a single property

And last, but not least , it must be easy to use.

This may seems like modest requirements, but in fact they rule out some of the existing validation frameworks.
Some of you may already be using the Validation Block from the Enterprise Library.

That basically leaves you with two options when it comes to configuration.

1. Using Attributes

2. External configuration using an XML format specifically designed to describe validation rules.

As this violates at least two of our requirements, we must investigate further.

The beauty of Lambda Expressions

I started to read this amazing article which have been resting in my reading backlog for a long time now.

He uses Lambda expressions to specify the validation rules and I immediately thought.. what a great idea?

Let the configuration be the code itself.

For what is attributes and XML configuration if not just another way of specifying what code to execute?

This must be it. Let's start defining some interfaces for our new library.

Imagine of we could something like

(c => c.CustomerID.Length < 5, "CustomerID cannot exceed five characters")  

First we need something that represents a validation rule

/// <summary>
/// Represents a validation rule.
/// </summary>
/// <typeparam name="T">The type that this <see cref="IValidationRule{T}"/> applies to.</typeparam>
public interface IValidationRule<T>
{
    /// <summary>
    /// Gets or sets the message used when the rule is broken.
    /// </summary>
    string Message { get; set; }
 
    /// <summary>
    /// Gets or sets the function delegate that points to the validating code. 
    /// </summary>
    Func<T, bool> Rule { get; set; }
}    

The validation rule is specific to the target type and now we just need some way of adding new validation rules.

/// <summary>
/// Represents a set of validation rules.
/// </summary>
/// <typeparam name="T">The target type that the validation rules applies to.</typeparam>
public interface IValidationRules<T>
{
    /// <summary>
    /// Adds a new validation rule.
    /// </summary>
    /// <param name="rule">The <see cref="Expression{TDelegate}"/> that contains the validating code.</param>
    /// <param name="message">The message to be used when a validation rule is broken.</param>
    void AddRule(Expression<Func<T, bool>> rule, string message);
 
    /// <summary>
    /// Gets all the <see cref="IValidationRule{T}"/> instances for the target type.
    /// </summary>
    /// <returns>An <see cref="IEnumerable{T}"/> that contains <see cref="IValidationRule{T}"/> instances.</returns>
    IEnumerable<IValidationRule<T>> GetRules();
 
    /// <summary>
    /// Gets all the <see cref="IValidationRule{T}"/> instances that applies to the target type and <paramref name="propertyName"/>.
    /// </summary>
    /// <param name="propertyName">The name of the property for which to retrieve the validation rules.</param>
    /// <returns>An <see cref="IEnumerable{T}"/> that contains <see cref="IValidationRule{T}"/> instances.</returns>
    IEnumerable<IValidationRule<T>> GetRules(string propertyName);
}

We can now add new validation rules and return them as a whole or only rules specific to one property.

You migth notice that there is no overload to AddRule that allows us to specify the target property.

How is it then possible to retrieve validation rules that applies to e.g. CustomerID?

Expression<Func<T,bool>> vs Func<T,bool>

While Lambda expression are truly powerful, but their real potential comes to show when wrapped by a Expression<T>.

Expression trees kan be thought of like code that has not yet been compiled. It is sort of like an AST(Abstract syntax tree).

We can inspect and even change expression trees before they are compiled and executed.

I'm not saying here that compiled code can not be altered, but that is a quite different story which we will look into later.

So let's just get back to expression trees.

So how is that going to help us with regards to the validation library?

Since the requirements states that we must be able to validate any given property, we need some way to

associate the expression and the target property.

The general rule here is if the expression references a property that belongs to the target type, we assoiate the expression with that property.

Example

(c => c.CustomerID.Length < 5, "CustomerId cannot exceed five characters")  

The CustomerID property is declared by the Customer class and we can associate the expression accordingly.

But how do we inspect the expression to determine the target properties?

The ExpressionVisitor

Working with expression trees takes some getting used to.

Luckally for us we have a very useful class available to us when we want to inspect or rewrite an expression tree.

The ExpressionVisitor class is actually not available to us directly, but you can find it in the MSDN documentation.

If you ever get to browse the source code of a Linq provider, you are very likely to see this class used all over.

It's purpose is basically to allow us to visit each node of the expression tree (visitor pattern) and reconstruct the tree for us if we make any changes to it.

Why do we want to make changes to the expression tree? Well, we will see in just a minute.

For now we just want to retrieve all target properties based on the lambda expression that makes up the validating code.

We go ahead and define an interface like this

/// <summary>
/// Represents a class that is capable of determining a set of 
/// </summary>   
public interface ITargetPropertyResolver
{
    /// <summary>
    /// Tries to determine the target property or properties that the validation <paramref name="expression"/> applies to.
    /// </summary>
    /// <param name="expression">The validation expression</param>
    /// <returns>An <see cref="IEnumerable{T}"/> that contains the target properties.</returns>
    IEnumerable<PropertyInfo> ResolveFrom(Expression expression);
}

And the implementation goes like

/// <summary>
/// Determines the properties that a validation expression should be associated with.
/// </summary>
[Implements(typeof(ITargetPropertyResolver))]
public class TargetPropertyResolver : ExpressionVisitor, ITargetPropertyResolver
{
    private readonly IList<PropertyInfo> _targetProperties = new List<PropertyInfo>();
 
    private Type _validationTargetType;
 
    /// <summary>
    /// Tries to determine the target property or properties that the validation <paramref name="expression"/> applies to.
    /// </summary>
    /// <param name="expression">The validation expression</param>
    /// <returns>An <see cref="IEnumerable{T}"/> that contains the target properties.</returns>
    public IEnumerable<PropertyInfo> ResolveFrom(Expression expression)
    {
        SetValidationTargetType(expression);
 
        Visit(expression);
 
        return _targetProperties;
    }
 
 
    /// <summary>
    /// Determines if the <paramref name="m"/> is considered a target property for the validation expression.
    /// </summary>
    /// <param name="m">The currently accessed member.</param>
    /// <returns><see cref="Expression"/></returns>
    protected override Expression VisitMemberAccess(MemberExpression m)
    {
        if (IsTargetProperty(m))            
            RegisterMemberAsExpressionTarget(m);                
 
        return base.VisitMemberAccess(m);
    }
 
    /// <summary>
    /// Sets the validation target types based on the validation expression
    /// </summary>
    /// <param name="expression">The validation expression.</param>
    private void SetValidationTargetType(Expression expression)
    {
        _validationTargetType = ((LambdaExpression)expression).Parameters[0].Type;
    }
 
    /// <summary>
    /// Determines if the <paramref name="memberExpression"/> is a property declared by the target type.
    /// </summary>
    /// <param name="memberExpression">The <see cref="MemberExpression"/> that current is being visited.</param>
    /// <returns><b>True</b> if the <paramref name="memberExpression"/> is a property and is declared by the target type.</returns>
    private bool IsTargetProperty(MemberExpression memberExpression)
    {
        return (memberExpression.Member.DeclaringType == _validationTargetType) && memberExpression.Member is PropertyInfo;
    }
 
    private void RegisterMemberAsExpressionTarget(MemberExpression memberExpression)
    {            
        _targetProperties.Add((PropertyInfo)memberExpression.Member);            
    }        
}

As we can see from the code the visitor class override the VisitMemberAccess method which is fired for every time a member is accessed in the lambda expression.

Then we basically just checks if the property is a target property by determining if the property is declared by the target type (e.g Customer)

So now we have our expression and we also know its target property/properties.

Didn't I mention something about rewriting the expression tree?

Coerce those Null values

Let's take another look at our little example

(c => c.CustomerID.Length < 5, "CustomerId cannot exceed five characters")

Does anybody spot something potentially wrong with this code? No?

If it is any consolation, neither did I until my unit test blew up in my face proclaiming a NullReferenceException somewhere.

Then it finally hit me. What happens if the target property is null? How could I have missed that?

And just when this library was all good and ready to jump into production.

Then I started to think about how to deal with this problem.

We could of course check the property value before executing the lambda expression, but then again the expression could target several properties and would have to check them all in order to safely execute the expression.

We could also require the lambda expression to include a check for null, but that seems a little intrusive and certainly violates the requirement that states ease of use.

If we only could make sure we had a value in place once the check is executed.

What we basically are looking for is turning this

(c => c.CustomerID.Length < 5, "CustomerId cannot exceed five characters")

into this

(c => (c.CustomerID ?? "").Length < 5, "CustomerId cannot exceed five characters")

That should take care of business, right?

But what we actually wanted to test for null in addition to the string length?

(c => c.CustomerID.Length < 5 && c.CustomerID != null, "CustomerId cannot be null or exceed five characters")

So what we need to do is coerce those null values into their default values unless an explicit check for null is intended.

That means that we need to turn it into this

(c => (c.CustomerID ?? "").Length < 5 && c.CustomerID != null, "CustomerId cannot be null or exceed five characters")

And since we are still working with expression trees, we can make the necessary changes by doing an expression tree rewrite.

Next we go ahead and define an interface to do the rewrite.

/// <summary>
/// Represents a class that is capable of rewriting the expression tree in such 
/// as way that member expressions don't return <c>null</c> values unless an explicit
/// check for <c>null</c> is intended.
/// </summary>
public interface IRuleRewriter
{
    Expression<Func<T, bool>> Rewrite<T>(Expression<Func<T, bool>> ruleExpression, IEnumerable<PropertyInfo> targetProperties);
}

And the implementation is once again based on the ExpressionVisitor class.

[Implements(typeof(IRuleRewriter))]
public class RuleRewriter : ExpressionVisitor, IRuleRewriter
{
    private readonly IList<MemberExpression> _excludeList = new List<MemberExpression>();
    private IEnumerable<PropertyInfo> _targetProperties;
 
    #region IRuleRewriter Members
 
    /// <summary>
    /// Rewrites the <see cref="ruleExpression"/> by replacing any <see cref="MemberExpression"/> with a <see cref="ConditionalExpression"/>
    /// where the member is not explicitly checked for <c>null</c>.
    /// </summary>
    /// <typeparam name="T">The target type to validate.</typeparam>
    /// <param name="ruleExpression">The validation expression.</param>
    /// <param name="targetProperties">The target properties for the <paramref name="ruleExpression"/> that are candidates for rewriting.</param>
    /// <returns><see cref="Expression{TDelegate}"/></returns>
    public Expression<Func<T, bool>> Rewrite<T>(Expression<Func<T, bool>> ruleExpression,
                                                IEnumerable<PropertyInfo> targetProperties)
    {
        _targetProperties = targetProperties;
        return (Expression<Func<T, bool>>) Visit(ruleExpression);
    }
 
    #endregion
 
    /// <summary>
    /// Check to see if a <see cref="MemberExpression"/> is part of an explicit check for <c>null</c>
    /// </summary>
    /// <param name="binaryExpression">The currently visited <see cref="BinaryExpression"/></param>
    /// <returns><see cref="BinaryExpression"/></returns>
    protected override Expression VisitBinary(BinaryExpression binaryExpression)
    {
        if (IsExplicitCheckForNull(binaryExpression))
            ExcludeFromMemberRewrite(binaryExpression);
        return base.VisitBinary(binaryExpression);
    }
 
    /// <summary>
    /// Replaces the <see cref="MemberExpression"/> with a <see cref="ConditionalExpression"/>
    /// that return the default value if the member yields null.
    /// </summary>
    /// <param name="memberExpression">The currently visited <see cref="MemberExpression"/></param>
    /// <returns>A <see cref="ConditionalExpression"/> if a rewrite has been performed, otherwise the original <see cref="MemberExpression"/></returns>
    protected override Expression VisitMemberAccess(MemberExpression memberExpression)
    {
        if (ShouldRewiteMemberExpression(memberExpression))
            return RewriteMemberExpression(memberExpression);
 
        return base.VisitMemberAccess(memberExpression);
    }
 
    private bool ShouldRewiteMemberExpression(MemberExpression memberExpression)
    {
        if (!IsTargetProperty(memberExpression) || IsMemberExcluded(memberExpression))
            return false;
        return MemberIsReferenceTypeOrNullableValueType(memberExpression);
    }
 
    private bool MemberIsReferenceTypeOrNullableValueType(MemberExpression memberExpression)
    {
        var propertyInfo = (PropertyInfo) memberExpression.Member;
        return !propertyInfo.PropertyType.IsValueType || propertyInfo.PropertyType.IsNullableType();
    }
 
 
    private Expression RewriteMemberExpression(MemberExpression memberExpression)
    {
        var propertyInfo = (PropertyInfo) memberExpression.Member;
        return Expression.Condition(GetTestExpression(memberExpression), GetDefaultValueExpression(propertyInfo),
                                    memberExpression);
    }
 
    private static BinaryExpression GetTestExpression(MemberExpression memberExpression)
    {
        return Expression.Equal(memberExpression, Expression.Constant(null));
    }
 
    private static UnaryExpression GetDefaultValueExpression(PropertyInfo propertyInfo)
    {
        return Expression.Convert(Expression.Constant(GetDefaultValue(propertyInfo.PropertyType)),
                                  propertyInfo.PropertyType);
    }
 
 
    private void ExcludeFromMemberRewrite(BinaryExpression binaryExpression)
    {
        if (IsTargetProperty(binaryExpression.Left))
            _excludeList.Add((MemberExpression) binaryExpression.Left);
        if (IsTargetProperty(binaryExpression.Right))
            _excludeList.Add((MemberExpression) binaryExpression.Right);
    }
 
    private bool IsMemberExcluded(MemberExpression memberExpression)
    {
        return _excludeList.Contains(memberExpression);
    }
 
 
    private bool IsExplicitCheckForNull(BinaryExpression binaryExpression)
    {
        if (IsNullConstant(binaryExpression.Left) && IsTargetProperty(binaryExpression.Right))
            return true;
        if (IsNullConstant(binaryExpression.Right) && IsTargetProperty(binaryExpression.Left))
            return true;
        return false;
    }
 
 
    private static bool IsNullConstant(Expression expression)
    {
        var constantExpression = (expression as ConstantExpression);
        if (constantExpression == null)
            return false;
        return (constantExpression.Value == null);
    }
 
    private bool IsTargetProperty(Expression expression)
    {
        var memberExpression = (expression as MemberExpression);
        if (memberExpression == null)
            return false;
        var propertyInfo = (PropertyInfo) memberExpression.Member;
        if (propertyInfo == null)
            return false;
        return _targetProperties.Contains(propertyInfo);
    }
 
 
    /// <summary>
    /// Gets the default value to be used as a surrogate for the supplied <c>null</c> value.
    /// </summary>
    /// <param name="type">The target type.</param>
    /// <returns>The default value as determined by the underlying value type.</returns>
    private static object GetDefaultValue(Type type)
    {
        //We need some special handling for the string data type 
        //since it is a reference type, but behaves like a value type.
        if (type == typeof (string))
            return string.Empty;
 
        return type.GetNonNullableType().GetDefaultValue();
    }
}

What we are doing here is that we replace the MemberExpression with a ConditionalExpression that returns the default value (based on the property type) if the property yields null.

Configuring your application

We have already stated that the validation target should not have to reference the validation library itself.

So where and how can we add new rules to our objects?

One simple solution would be to retrieve the IValidationRules<T> instance and start adding new rules.

example

var rules = _serviceContainer.GetService<IValidationRules<Customer>>();

rules.AddRule( c=> c.ContactName != null,"ContackName can not be null");

But that code would have to reside somewhere, right?

In order to really make life easy when adding new rules, take a look at the IRuleInjector<T> interface.

    /// <summary>
    /// Represents a class that is capable of injecting additional validation rules
    /// that should apply to the target type.
    /// </summary>
    /// <typeparam name="T">The target type to validate.</typeparam>
    public interface IRuleInjector<T>
    {
        /// <summary>
        /// Allows additional validation rules to be added to the <see cref="IValidationRule{T}"/> instance.
        /// </summary>
        /// <param name="validationRules">The <see cref="IValidationRules{T}"/> instance
        /// that contains the validation rules for the target type.</param>
        void Inject(IValidationRules<T> validationRules);
    }

All we need to do is to implement the interface and make sure that it is located in an assembly loaded by the service container.

example

    [Implements(typeof(IRuleInjector<IOrderDetail>))]
    public class SampleRuleInjector : IRuleInjector<IOrderDetail>
    {
        public void Inject(IValidationRules<IOrderDetail> validationRules)
        {
            validationRules.AddRule(od => (decimal)od.Discount < od.UnitPrice
                ,"Discount must be less than the unit price");
        }
    }

This also means that we can add new rules without ever recompiling the application.

Validation in action

Now we pretty much have all the expressions in place and it is time to actually validate something.

That something may be an object where we validate everything or an object where we want to validate just one property.

Having the ability to validate just one property comes in very handy when using this library in conjunction with the IDataErrorInfo interface.

Using the code

We have already looked at how we add new validation rules to a target type and its time to see how we can execute the actual validation

To validate the whole object

var validator = _serviceContainer.GetService<IValidator<Customer>>();
string result = validator.validate(someCustomer);

To validate one single property

var validator = _serviceContainer.GetService<IPropertyValidator<Customer>>();
string result = validator.validate(someCustomer,"CustomerID");

The IDataErrorInfo interface

As we can see using the IPropertyValidator<T> fits very well together with implementing the IDataErrorInfo interface.

This interface has to be implemented by the binding target and how can we do that without having to reference the validation library.

It is also very related to the UI and the data binding mechanism so it does not really belong in our objects either. What a puzzle.

A Proxy to the rescue

I sometimes get asked about why I have my domain object implement an interface and this is one of the reasons why.

By using interfaces for our domain object, we can create proxies for them and those proxies can implement any additional interface.

Let's stick with the customer object (Northwind) and see how it looks like

The interface

    public interface ICustomer
   {
       string CustomerID { get; set; }
       string CompanyName { get; set; }
       string ContactName { get; set; }
       string ContactTitle { get; set; }
       string Address { get; set; }
       string City { get; set; }
       string Region { get; set; }
       string PostalCode { get; set; }
       string Country { get; set; }
       string Phone { get; set; }
       string Fax { get; set; }
       IList<ICustomerCustomerDemo> CustomerCustomerDemo { get; }
       IList<IOrder> Orders { get; }
   }

When asking the service container for an ICustomer instance, the only requirement for the concrete class is that it implement ICustomer.

But it can also implement addition interfaces.

The Linfu framework has a very powerful proxy library and we can actually use that to have our domain objects implement IDataErrorInfo at runtime.

For those of you wondering what a proxy really is, we can sum it all up by saying that it sits between the calling code and the actual implementation.

You can read more about them here.

First we need some type of interceptor that gets called when calls are being made to the proxy instance.

    [Implements(typeof(IInterceptor),LifecycleType.OncePerThread, ServiceName = "DataErrorInfoInterceptor")]
    public class SampleDataErrorInfoInterceptor : IInterceptor, IInitialize
    {
        private IServiceContainer _serviceContainer;

        private object _actualTarget;

        private Type _targetType;

        public SampleDataErrorInfoInterceptor(object actualTarget, Type targetType)
        {
            _actualTarget = actualTarget;
            _targetType = targetType;
        }

        public object Intercept(IInvocationInfo info)
        {
            if (info.TargetMethod.Name == "get_Item")
            {
                var propertyValidatorType = typeof (IPropertyValidator<>).MakeGenericType(_targetType);
                var propertyValidator = _serviceContainer.GetService(propertyValidatorType);
                var result = propertyValidatorType.DynamicInvoke(propertyValidator,"Validate", new[] {_actualTarget, info.Arguments[0]});
                return result;
            }
            return info.TargetMethod.DynamicInvoke(_actualTarget, info.Arguments);
        }

        public void Initialize(IServiceContainer source)
        {
            _serviceContainer = source;
        }
    }

The interceptor forward calls to IDataErrorInfo.Item[] to the IPropertyValidator<T> that knows how to validate the target type.

The last thing we need to is making sure that a proxy is returned when a request for an ICustomer instance is made.

Using an IPostProcessor enables us to inspect the service instance and return our proxy instance.

    [PostProcessor]
    public class SampleDomainModelPostProcessor : IPostProcessor
    {
        private IProxyFactory _proxyFactory;

        public void PostProcess(IServiceRequestResult result)
        {
            if (result.ServiceType.Namespace.Contains("DomainModel"))
            {
                var proxyFactory = CreateProxyFactory(result.Container);
                var interceptor = result.Container.GetService<IInterceptor>("DataErrorInfoInterceptor",result.OriginalResult,result.ServiceType);
                var proxy = proxyFactory.CreateProxy(result.ServiceType, interceptor, typeof (IDataErrorInfo));
                result.ActualResult = proxy;
            }
        }

        private IProxyFactory CreateProxyFactory(IServiceContainer serviceContainer)
        {
            if (_proxyFactory == null)
                _proxyFactory = serviceContainer.GetService<IProxyFactory>();
            return _proxyFactory;
        }
    }

The proxy now implements both the ICustomer and the IDataErrorInfo interface.

        [Test]
        public void ShouldImplementIDataErrorInfo()
        {
            var customer = _serviceContainer.GetService<ICustomer>();
            Assert.IsTrue(typeof(IDataErrorInfo).IsAssignableFrom(customer.GetType()));
        }

As a result of this we have now added transparent validation to our domain objects and all the plumbing
needed to visualize this in the UI has been abstracted away from the object itself.

Asynchronous Method Invocation

2008-09-01T11:28:00.001-07:00

I'm currently in the process of developing a plug-in framework that enables business developers to create individual modules/plug-in's to be hosted in a management console.

It soon became an issue that we would have to support some kind of multithreading features to avoid blocking the UI.

IMHO, the UI thread (main thread) should have one task and that is making the application look alive to the end user.

We looked at several options from running each plug-in in its own app domain to loading forms on different threads. Nothing really ended up like we wanted to. Too much code, too much setup. There had to be a better way and it had to be easy to use.

The Background Worker

Our first thought was that the business developers could use the Background Worker to do their asynchronous stuff.

While this certainly solves the problem we still thought it would be good if we did not need to set up event handlers, pass arguments as objects and so on.

The good thing about it though, is that it takes care of invoking the RunWorkerCompleted event on the appropriate thread. This way you don't run into cross-thread exceptions when accessing a UI component.

The IAsyncInvocator interface

/// <summary>
/// Represents a class that is capable of invoking a method asynchronously. 
/// </summary>
public interface IAsyncInvocator
{
    /// <summary>
    /// Executes the function as described in the <paramref name="func"/> delegate.
    /// </summary>
    /// <typeparam name="TTarget">The type of target that will be subject for invocation.</typeparam>
    /// <typeparam name="TResult">The type of result from the method invocation.</typeparam>
    /// <param name="target">An instance of <paramref name="{TTarget}"/> </param>
    /// <param name="func">Represents the method to be invoked asynchronously.</param>
    /// <param name="callBack">Represents the method to be called after method has been executed.</param>
    void AsyncInvoke<TTarget, TResult>(TTarget target, Func<TTarget, TResult> func, Action<TResult> callBack);
}

As mentioned we needed a simple API to let our class library users invoke they asynchronous methods.
For those of you not familiar with the Func<T> and Action<T> delegates, this interface may look a little complicated.
Lets put it to use and discover that is not all that complicated.

invocator.AsyncInvoke(this, m => m.SomeMethod(),r => Console.WriteLine("Result: {0}" ,r));

That's it. The method "SomeMethod" is invoked asynchronously and the result is passed to the callback that in our little example just prints out the result to the console.

Oh, I almost forgot

It's kind of funny actually, following the TDD (Test Driven Development) pattern, I often find myself forgetting about this last tiny detail:)

Here is the code implementing the interface

[Implements(typeof(IAsyncInvocator),LifecycleType.OncePerRequest)]
public class AsyncInvocator : IAsyncInvocator
{               
 
    #region IAsyncInvocator Members

    /// <summary>
    /// Executes the function as described in the <paramref name="func"/> delegate.
    /// </summary>
    /// <typeparam name="TTarget">The type of target that will be subject for invocation.</typeparam>
    /// <typeparam name="TResult">The type of result from the method invocation.</typeparam>
    /// <param name="target">An instance of <paramref name="{TTarget}"/> </param>
    /// <param name="func">Represents the method to be invoked asynchronously.</param>
    /// <param name="callBack">Represents the method to be called after method has been executed.</param>
    public void AsyncInvoke<TTarget, TResult>(TTarget target, Func<TTarget, TResult> func, Action<TResult> callBack)
    {           
        AsyncOperation asyncOperation = AsyncOperationManager.CreateOperation(null);
        ThreadPool.QueueUserWorkItem(state =>
                                         {
                                             TResult result = func(target);
                                             asyncOperation.Post(argument => callBack(result), null);
                                             asyncOperation.OperationCompleted();
                                         });
    }

    #endregion
}

As you may notice, the AsyncOperationManager comes in very handy in this scenario. In short it takes care of executing the callback delegate on the calling thread.
Actually this is pretty much the same way the BackGroundWorker handles the RunWorkerCompleted event.
The observant reader may have noticed the Implements attribute at the class level. It is just a configuration attribute so that my favoritte IOC container can gain awareness over this type.

TDD and IOC(Inversion of Control) goes hand in hand and I strongly recommend that you check out the LinFu framework for a container that actually is understandable. It provides a very simple API and has a 100 percent test coverage. The project owner's name is Philip Laureano and he is among, if not the most inspiring individual I have met in my 15 years as a developer. My thanks goes out to you, my friend.

Welcome to my new blog

2007-11-29T13:39:00.000-08:00