Tuesday, November 30, 2010

I’m currently building some JSON services for a client using ASP.NET MVC. One of the things I want to implement is HATEOS (read the link) so I need to be able to build the URLs (or URIs) of the endpoints that I can then embed into the JSON I return to the client.

I wanted to be able to take some route values, controller=”abc”, action=”xyz”, id=10, and return a virtual path. Unfortunately System.Web.Routing makes this a bit of trial, but you can make it work. I’ve wrapped my implementation up in a little UriBuilder class. Here’s a test showing it working:

I’ve been looking at Sammy.JS recently. It’s a lightweight Javascript framework for managing transitions on your page. It extends jQuery. The neat trick it uses is to leverage the anchor part of the URI – that’s the bit after the ‘#’ to provide routes into your javascript. If you’ve used the new routing framework in ASP.NET you’ll understand it straight away.

Here’s a quick example I’ve put together. We’ve got three links with three paragraphs. As you click the links the related paragraph appears.

The big deal is that I now have a URI to each paragraph and normal browser functions like the back button work. Go on, you can try it. I can correctly link straight to a particular state of my Ajax application, and you know what a PITA that can be.

"Inversion of Control is highly associated with dependency injection and the dependency inversion principle. Dependency injection is the main method to implement Inversion of Control."

As I understand it Inversion of Control and the Dependency Inversion Principle are both different names for the same 'principle' of OO design. That you should decouple your software by depending on abstractions rather than implementations.

Dependency Injection is a 'pattern' used to implement Inversion of Control/Dependency Inversion. This is either implemented as constructor injection, where dependencies are ‘injected’ via constructor parameters, or as property injection where dependencies are injected via property setters.

This is just my understanding of these terms. If you think I’m wrong please comment and maybe we can arrive at some accepted definitions.

Thursday, November 18, 2010

I recently received a very nice email asking about one of my ‘10 Advanced Windsor Tricks’ posts where I’d stated, without really backing it up:

“Without this trick you would have to reference the container itself, which is an IoC anti-pattern of epic proportions.”

So why is referencing the IoC container an anti-pattern?

The hint is the name 'Inversion of Control'. IoC a is core principle of OO design, the idea being that you don't depend on concrete implementations, but on abstractions (in our case, interfaces). We want to build our software like Lego, out of independent components, that supply to their environment all the information about what they need to work. That information is described in interfaces. When we have a service like this:

… it's telling us two things, firstly that it supplies a service described by the ISomeService interface, that is, anywhere where an ISomeService is required, MyService can be supplied. The second thing it tells us is that it requires ISomeDependency to work. It doesn't care how that's implemented, just that whatever is supplied obeys that contract.

The important point here is that MyService is described entirely in terms of it’s own domain. Inversion of Control is a principle not a technology. We don’t need a container at this stage.

You might argue that the container is what it needs to in order to function, but we're really lying here, we could be using any dependency internally and it's not communicated to the outside world. Rather than describing our component in terms of its own domain, we’re polluting it with infrastructure concerns (the container).

By doing this you are making your life harder than it needs to be. Say I want to write a unit test for MyService, I now have to mock IContainer and get it to pass some mock of ISomeDependency, it's twice as much work. So not only have I lost information, I've made my own life as a developer harder.

But the most important message that this kind of code is carrying, is that the author has failed to grasp the real genius of IoC containers. I’ll try an example:

They are all registered with my IoC container. Now when I resolve IComponent1 like this:

var component1 = container.Resolve<IComponent1>();

the container will first create an instance of Component3, then an instance of Component2 passing it the Component3 instance in its constructor. Then finally it will create an instance of Component3 passing the Component2 instance to its constructor which it returns to the caller.

Deep inside our infrastructure, there is a single call to the container to get the root object of our application (our core application class if you will), all the cascading dependencies from that root object are discovered, constructed and supplied by the container. That's the magic of IoC containers, they glue our application together, but you never see them except for that initial, single resolve call.

So referencing the container itself is an anti-pattern of epic proportions, because it means you’ve failed to understand what an IoC container is. It's a bit like buying a tractor, hitching it up to a team of horses and attempting to plow a field with it.

Monday, November 08, 2010

Here’s a video of me presenting Tardis Bank at £5App last week. It was late in the evening and we’d all had a few beers, so it’s worth watching just for the heckling :) Many thanks to Ian Ozsvald for sharing this. The whole evening was excellent, it’s well worth checking out the other videos on Ian’s blog.

My web application TardisBank (a pocket money bank account for kids) needs to show users the currency symbol for their location. So UK users should see ‘£’, but US users should see ‘$’. I’d thought that I would have to ask the user to choose a currency symbol when they signed up, but Dylan Beattie had a much better idea:

Say we have a number of asynchronous tasks that we want to execute in series because the result of the first task is an input value to the second task, and the result of the second task is an input to the third. To demonstrate, I’ve created two simple task generators:

I want to create an int and then add 3 to it, and then add 4. It’s difficult to compose these using the standard ‘ContinueWith’ callback:

publicvoid ComposeWithContinueWith()
{
var result = CreateInt(2)
.ContinueWith(t1 => AddInts(t1.Result, 3)
.ContinueWith(t2 => AddInts(t2.Result, 4))
);
// result is the first task, how do you get the third task's result?
}

You can simply put two lots of ‘Unwrap()’ at the end of the expression:

However, there is an implementation in the ParallelExtensionsExtras assembly. I confused myself (it happens a lot) because I’d included the ParallelExtensionsExtras for the Task extension methods on SmtpClient and SqlDataReader, and has simply assumed that Task<T> has the Linq extension methods built in.

Code Rant

Notepad, thoughts out loud, learning in public, misunderstandings, mistakes. undiluted opinions. I'm Mike Hadlow, an itinerant developer. I live (and try to work in) Brighton on the south coast of England.

All code is published under an MIT licence. You are free to take it and use it for any purpose without attribution. There is no warranty whatsoever.