Dapper - A Simple ORM

Entity Framework

Entity Framework is a full featured ORM. This is nice when performance is not important but rapid development is. Coding Linq statements instead of stored procedures can speed implementation dramatically.

EF's ease of use has trade-offs. All the behind the scenes work means slower performance and frustrating gotchas. Occasionally EF's generated SQL differs from the desired result. This inevitably necessitates a greater understanding of EF's inner workings. At that point it's just easier to write your own SQL.

Dapper

Dapper is a Micro-ORM. It focuses on simplifying database interactions with extension methods for query and execute commands. It also auto-maps values to POCO objects.

That's more or less it. Because Dapper's not managing relationships and data in memory its performance is an order of magnitude better.

According to Dapper's Github Page, “Select mapping over 500 interactions and POCO serializations” section:

• Hand Coded: 47ms
• Dapper: 49ms
• Entity Framework: 631ms

There is almost no performance hit because Dapper doesn't do too much.

Stored Procedure Example

Let's write code to return a list of Diamond Club Members from a Stored Procedure.

Here's our POCO:

private class Member
{
    public string Guid {get;set;}
    public string Name {get;set;}
    public string MemberType {get;set;}
}

Let's look at an ADO.NET example:

private IEnumerable<Members> GetAllDiamondClubMembers()
{
    using (var sqlConnection = new SqlConnection(connectionString))
    using (var sqlCommand = new SqlCommand(
        "dbo.GetAllMembers", sqlConnection){
             CommandType = CommandType.StoredProcedure }) {

        sqlCommand.Parameters.Add("@MemberType", SqlDbType.VarChar)
            .Value = "DiamondClub";

        sqlConnection.Open();

        var sqlDataReader = sqlCommand.ExecuteReader();

        var members = new List<Members>();

        while(sqlDataReader.Read())
        {
            members.Add(new Member
            {
                Guid = sqlDataReader["Guid"],
                Name = sqlDataReader["Name"],
                MemberType = sqlDataReader["MemberType"]
            });
        }

        sqlConnection.Close();

        return members;
    }
}

In the above example we are:

1. Creating a SQL Connection
2. Creating a SQL Command
3. Loading the SQL Command
4. Opening the SQL Connection
5. Executing the Stored Procedure
6. Iterating through the returned values
7. Mapping each individual value
8. Closing the connection
9. Returning the results

Dapper dramatically simplifies this:

private IEnumerable<Members> GetAllDiamondClubMembers()
{
    IEnumerable<Members> results;

    using (var sqlConnection = new SqlConnection(connectionString))
    {
        sqlConnection.Open();
        results = sqlConnection.Query("dbo.GetAllMembers", 
            new { MemberType = "DiamondClub" },
            commandType: CommandType.StoredProcedure);
    }

    return results;
}

Now we:

1. Create the SQL Connection
2. Open the SQL Connection
3. Run the Query
4. Return the results

Dapper has taken care of most of the rudimentary details for us. This is a healthy compromise between Entity Framework's performance hit and ADO.NET's code requirements.

Microsoft Unity IoC Container

SOLID

Because we’re following SOLID code design we should have:

• Small classes
• Concrete classes that implement interfaces (with very few exceptions)
• Any interactions with a concrete class should be done using the interface
• Classes that other classes depend on should be injected into them during instantiation (preferably using the constructor)

A natural outgrowth of these rules is IoC.

IoC

IoC stands for Inversion of Control. It’s a byproduct of the Dependency Inversion principal. Instead of classes higher in the dependency chain determining what concretion of a class they should be using, a separate context determines which concretions get used.

This is confusing so let’s take a look at some sample code.

public class A
{
    public void LogIt()
    {
        var log = new Log();
        log.LogMe("I'm not testable!");
    }
}

public class Log
{
    public void LogMe(string message)
    {
        Console.WriteLine(message);
    }
}

In this example A creates an instance of Log and calls the LogMe method. A is Higher on the dependency chain and determines which class to use to call the LogMe method.

This is bad for a few reasons:

• I can’t test A desperately from Log. For larger classes and more dependencies this makes unit testing impossible. As the different possibilities pile up (code paths or combinations) testing become exponential.
• If I want to change A's use of Log but preserve Log in it's current form (if other classes use Log) I am forced to modify A as well. This is especially frustrating if I want to call LogMe still.

Let’s take a look at a more maintainable code base:

public class A : IA
{
    private readonly ILog _log;
 
    public A(ILog log)
    {
        _log = log;
    }

    public void LogIt()
    {
        _log.LogMe("A is now testable!");
    }
}

public interface IA
{
    void LogIt();
}

public class Log : ILog
{
    public void LogMe(string message)
    {
        Console.WriteLine(message);
    }
}
 
public interface ILog
{
    void LogMe(string message);
}

The above example's code has increased some because we inject a concrete instance of Log as an interface ILog into A. A is now not in charge of determining what concrete implementation of ILog is used. We've also created interfaces for both A and Log.

This is:

• Testable: I can test A and Log separately.
• Swappable: If I need to I can specify a different concretion of ILog with no modification to A.

Notice that the concreate implementation of ILog is injected into A’s constructor and the interface ILog is private inside of A. This is called Constructor Injection.

There’s also a concept called Property Injection where a class exposes its dependencies as public properties. This is not a good idea as other classes could change your dependencies.

Enter MS Unity IoC Container

This leaves us with a problem. How do we organize and assemble all these classes together? In particular, if we have lots of small classes that call each other there’s going to be a lot of work done up front.

You can manually assemble the classes when your application first starts but it quickly becomes chaos and hard to read.

How do we avoid the mess that manually assembling dependencies together creates? Inversion of Control (IoC) Containers to the rescue.

IoC Containers provide a framework for organizing and managing dependencies inside your application. We will be using Microsoft Unity IoC Container in this example to assemble our dependency chain.

Let’s take a look at some code:

public static void AssembleDependencies()
{
    var unityContainer = new UnityContainer();

    unityContainer.RegisterInstance<ILog>(new Log());
    
    unityContainer.RegisterType<IA, A>(
        new InjectionConstructor(
            container.Resolve<ILog>()
        )
    );
}

RegisterType tells Unity to create a new instance of the concrete class anytime one is needed. In our example if A get's used multiple times Unity will create new instances each time.

RegisterIntance tells Unity to create and use only one instance for a specific lifetime. More often then not you will only need one instance of a logger (Log) for your application so here RegisterInstance only creates one.

This is kind of like the difference between using a Factory design pattern and a Singleton design pattern:

• Factory is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created.
• Singleton is a design pattern that restricts the instantiation of a class to one object.

RegisterType is a kind of Factory pattern with more capability. You use it when a new instance of a class is needed each time that class is used.

RegisterInstance is a kind of Singleton pattern with more capability. You use it when you only want one instance of a class in the whole application. However, you can also tell Unity when you want to expire the class and create a new one as well.

unityContainer.RegisterInstance<ILog>(new Log());

I used RegisterInstance for Log. In most applications you will only need one instance of a Logger. In this case we create the instance of Log and associate it with ILog. Now anytime unity is asked to resolve ILog it will create a concrete implementation of Log and return it as ILog.

unityContainer.RegisterType<IA, A>(
    new InjectionConstructor(
        container.Resolve<ILog>()
    )
);

I used RegisterType for A. Since A will be created more than once we want to give Unity instructions about what to inject into it and not actually create an instance now. InjectionConstructor is what keeps track of what dependencies should be injected into the constructor of A.

Note that we can now inject A in another class by resolving IA:

new InjectionConstructor(
    container.Resolve<IA>()
)

We've has only scratched the surface of Microsoft Unity IoC capabilities but I hope I've provided you a good start to developing more manageable code bases.

Web API 2 Message Handlers and Filters

Message Handlers

Custom Message Handlers

Custom message handlers are used for cross cutting concerns like logging or authorization.

Lets look at the Message Handler Pipeline we will be building:

HttpServer gets the initial message from the network. FooHandler and LogEverythingHandler are custom handlers created for our cross cutting concerns. HttpRoutingDispatcher functions as the last handler in the list responsible for sending the message to the HttpControllerDispatcher. The HttpControllerDispatcher then finds the appropriate controller and sends the message to it.

Let’s take a look at some code:

public class FooHandler : DelegatingHandler
{
    private readonly IBarProvider _provider;

    public FooHandler(IBarProvider provider)
    {
        _provider = provider;
    }

    protected async override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        System.Threading.CancellationToken cancellationToken)
    {           
        if (_provider.DoesRequestContainBar(request))
        {
            return await base.SendAsync(request, cancellationToken);
        }

        var response = request.CreateErrorResponse(HttpStatusCode.BadRequest, 
            "Request does not contain bar.");

        return response;
    }
}

The following 3 rules need to be followed to create a custom message handler:

1. Your class must inherit from the DelegatingHandler class.
2. You must implement the SendAsync class.
3. You must call base.SendAsynch to pass the message to the next custom message handler.

If we wanted to we could create another class to log every request to our API.

In order to tell Web API that we want these custom message handlers added to the pipeline we need to add some code the WebApiConfig class.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MessageHandlers.Add(new FooHandler());
        config.MessageHandlers.Add(new LogEverything());
    }
}

Execution Order

With our custom message handlers added to the pipeline the following becomes the order of execution:

• HttpServer
• FooHandler
• LogEverything
• HttpRoutingDispatcher
• HttpControllerDispatcher

This illustrates how custom message handlers give us the ability to apply general rules to all the messages coming into our API’s.

Filters

This quote beautifully illustrates the difference between Handlers and Filters:

“The major difference between their two is their focus. Message Handlers are applied to all HTTP requests. They perform the function of an HTTP intermediary. Filters apply only to requests that are dispatched to the particular controller/action where the filter is applied.”

Filters get applied to the individual controllers using attribute tags above a class or method.

Global Exception Filters

We can add exception filters to controller methods.

Let’s take a look at the following Filter and corresponding Controller.

public class UnauthorizedFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(HttpActionExecutedContext context)
    {
        if (context.Exception is UnauthorizedException)
        {
            context.Response =
                new HttpResponseMessage(HttpStatusCode.Unauthorized);
        }
    }
}

public class ProductsController : ApiController
{
    [UnauthorizedFilterAttribute]
    public Baz GetBaz(int id)
    {
        throw new UnauthorizedException("This method is not authorized.");
    }
}

In the above example UnauthorizedFilterAttribute is decorating ProductsController’s GetBaz method.

This gives us a clean separation between exception handling and controller logic. This also allows us to reuse the exception filter.

However, we can also make our exception filters global.

public sealed class GlobalExceptionFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(
        HttpActionExecutedContext httpActionExecutedContext)
    {
        if (httpActionExecutedContext != null)
        {
            if (httpActionExecutedContext.Exception is FooException)
            {
                var fooException = 
                    httpActionExecutedContext.Exception as FooException;
                httpActionExecutedContext.Response = 
                    new HttpResponseMessage(fooException.Code)
                {
                    Content = new StringContent(fooException.Message)
                };
            }
            else
            {
                httpActionExecutedContext.Response =
                    new HttpResponseMessage(
                        HttpStatusCode.InternalServerError)
                {
                    Content = new StringContent("There was a problem!")
                };
            }
        }
    }
}

Our GlobalExceptionFilterAttribute inherits from the ExceptionFilterAttribute. It also has only one overridden method named OnException. This class handles the response that should be sent back to the client.

public sealed class GlobalLogFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(
        HttpActionExecutedContext httpActionExecutedContext)
    {
        if (httpActionExecutedContext != null)
        {
            Logger logger = new Logger();
            logger.Error("There was an exception: {0}",
                httpActionExecutedContext.Exception.Message);
        }
    }
}

In the case of the GlobalLogFilterAttribute we can handle logging errors.

We now have a mechanism to:

• Log exceptions at the controller level
• Handle Errors that arise from the controller level

If all of our controller methods have the same logging and client exception response needs we've saved lots of coding. We've also ensured that fixes to the logging and client exception response don’t get partially implemented across only some controllers.

How do these “Global” exceptions get applied?

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();

        config.Filters.Add(new GlobalLogFilterAttribute());
        config.Filters.Add(new GlobalExceptionFilterAttribute());
    }
}

Inside the WebApiConfig class the HttpConfiguration has a global filter list that can have custom Filters added to it.