Depending on Runtime Data

Being assigned to do some refactoring of some controller actions at work, one of the tasks was to simplify how we got values from the request.

I was a bit surprised how we actually got values from the request. While not remembering how it exactly looked like, it was something along the lines of the following:

1
2
3
4
5
6
7
8
9
10
[Authorize, HttpGet, Route("api/comments/{id:int}"]
public IHttpActionResult GetComment(int id)
{

var username = Request.Current.User.Identity.Name;
var source = Request.Headers.GetValues("Source").FirstOrDefault();

var repository = new CommentRepository(username, source);
var comment = repository.Get(id);
return Ok(comment);
}

In my opinion you should never inject runtime values to any components, as they are an implementation detail.

Don’t inject runtime data into components during construction; it causes ambiguity, complicates the composition root with an extra responsibility and makes it extraordinarily hard to verify the correctness of your DI configuration. My advice is to let runtime data flow through the method calls of constructed object graphs. – Steven van Deursen.

Introduction to CQRS+ES (Part 1)

CQRS stands for Command Query Responsibility Segregation, and this pattern (or “architectural pattern”) has forever changed my way of designing and building applications.

In my following series on CQRS, I will do my best in explaining why this pattern is one of my favorites and perhaps making it your new favorite as well. Greg Young, Martin Fowler and many other writers on CQRS, has inspired me.

The first time I was introduced to CQRS, I thought I was a hard thing to implement. However, it quickly turned out to be the exact opposite and the little overhead it gives you, will benefit you for years in terms of maintaining code.

I believe people think that CQRS is hard, because it forces you to think about how you structure your code. There is some very specific (few) rules associated with CQRS you will have to get under your skin.

Unit-testing routes with Web API

One of the cool features of Web API, is that you can define the routes using attributed routing. I really like this approach, but it can also lead to misspelling which in the end can cause invalid routes.

To avoid that, you should really test that all the routes matches the right controller, the right action and the right http request type. In order to that, you must have a lot of test setup code for just faking the http request. However, with this little extension method, it will be both fun and easy to test.

Let us begin by taking this controller and action:

1
2
3
4
5
6
7
8
9
10
11
12
[RoutePrefix("person")]
public class PersonController : ApiController {

[HttpGet]
[Route("{id:int}", Name = "Person.GetPersonById")]
public IHttpActionResult GetPersonById(int id)
{

var person = new Person { Id = id }; // Should probably be a database query. :-)
return Ok(person);
}

}

In the example above, we want to verify that the http://localhost/api/person/1 route is matching the action GetPersonById(int id) with the argument 1 on PersonController and with a GET request.

It is straight forward to test this, with this extension method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[Fact]
public void RouteName_GetPersonById_ShouldRouteToPersonController_GetPersonById()
{

// Arrange
var configuration = new HttpConfiguration();
RouteConfig.RegisterRoutes(configuration); // Your RouteConfig from your Web API project.
configuration.EnsureInitialized();

// Act and assert
configuration.AssertRouteEqualTo<PersonController>("http://localhost/api/person/1",
controller => controller.GetPersonById(1), HttpMethod.Get, new Dictionary<string, object>
{
{ "id", 1 }
}
);
}

Please note, it is important to call the configuration.EnsureInitialized(); extensions to make sure the routes are correctly mapped, before asserting the route. If you do not do that, an exception will be thrown.

Now, lets take a look on how this AssertRouteEqualTo<TController>(...) extension method looks like.