Command and Query Handlers

In my previous post, I talked about some Command and Query handlers. The implementation I made is in .NET using C#. Here is what a command handler looks like:

public interface ICommandHandler<in TCommand> where TCommand : ICommand
{
     void Handle(TCommand command);
}

public class DeleteUserCommand : ICommand
{
    public Guid Id { get; set; }
}

public class DeleteUserCommandHandler : ICommandHandler<DeleteUserCommand>
{
    private readonly ISession _session;

    public DeleteUserCommandHandler(ISession session)
    {
        _session = session;
    }

    public void Handle(DeleteUserCommand command)
    {
        //handle command  
    }
}

There is also a command dispatcher that will dispatch the necessary handlers to execute the commands. This one does it synchronously, but it can be turned async quite easily.

public class DefaultCommandBus : ICommandBus
{
   ...
   public void SubmitCommand<TCommand>(TCommand command) where TCommand : ICommand
   {
      var handler = _commandHandlerFactory.GetHandler<TCommand>();
      try
      {
          handler.Handle(command);
      }
      finally
      {
          _commandHandlerFactory.ReleaseHandler(handler);
      }
   }
}

CommandHandlerFactory simply resolves the required handler using a DI container and is also reponsible for releasing the handler.

On the query side, there is a QueryService that executes the query and returns the result. This makes some use of the dynamic keyword trickery to provide a strongly typed API.

public interface IQuery<TResult> : IQueryBase {}

public interface IQueryHandler<in TQuery, out TResult> : IQueryHandler where TQuery : IQuery<TResult>
{
   TResult Execute(TQuery query);
}

public class QueryService
{
  public TResult ExecuteQuery<TResult>(IQuery<TResult> query)
  {
     var handlerType = typeof (IQueryHandler<,>).MakeGenericType(query.GetType(), typeof (TResult));
     var handler = _container.Resolve(handlerType);
     try
     {
        return (TResult)((dynamic)handler).Execute( (dynamic)query);
     }
     finally
     { 
        _container.Release(handler);
     }
  }
}

You can simply use the query as follows, and it will return a strongly typed result.

var query = new SearchUsersQuery { SearchTerm = "term" };
var result = _queryService.ExecuteQuery(query);
Advertisements

Command and Query Seperation

Command and Query Responsibility Separation, or CQRS, has been a term popping up quite often recently. It is definitely not the solution to everything, but it certainly makes some kind of solutions better. There are some frameworks to make the implementation easier, such as NCQRS and it certainly is very interesting, but it’s still very much in infancy.

If you would go with the full CQRS + Event Sourcing solution, depending on the experience and skill level of the developers the project might end up being much more costly than expected, even if CQRS + Event Sourcing offers superior architecture in many cases and can be applied to many problems, it doesn’t mean it’s always the correct answer.

I recently did an implementation of a CQRS-inspired solution, without using the full blown route using event sourcing. The requirements were as follows:

  • All the queries need to be filtered according to user’s privilege level.
  • All the commands need to pass through an authorization layer.
  • All changes to system need to be logged, at the command level.
  • It should be possible to expose all the functionality of the system through simple APIs.

Applying the CQRS principle in this case makes it easier write Query and Command Handlers that are able to deal with these kind of requirements. There are two sets of objects, Commands and Queries, each with corresponding handlers. QueryHandlers work synchronously and respond to Query objects. CommandHandlers as per CQRS do not return any results, and can work either synchronously or asynchronously, and process Command objects. QueryHandlers are not allowed commit any transactions (though this is not enforced by the code at this point). QueryHandlers work with a filtering layer that filter any results returned. CommandHandlers work with an authorization layer that authorizes every command in terms of a user context. Commands succeed as a whole, or fail as a whole. Both types of handlers work against the same data store. The query and command layers are the only possible interaction with the underlying data store, the only notable exception being the “authentication” layer. Performance isn’t an issue at this point so there hasn’t been any need to go with a different “Read Model” which offers a denormalized view.

When exposing APIs, it is quite easy to expose all the Query and Commands in a straightforward way and have all the logic for filtering and authorization still intact.

Of course all of this can be achieved by simpling turning everything into Requests and writing Requests Handlers or doing standard CRUD, but having the seperation makes it possible to make all commands function asynchronously or add some kind of caching layer for the queries later on.