A Taste of Mistery

Recently I got involved with the Agatha open-source project.

Mainly because the lead dev of it wanted to use QuickNet in order to test it.

I follow his blog and it looked like a promising lib. In the past I had to jump some of the hurdles dotnet distributed development throws at you, and almost always implemented a non-traditional solution in order to avoid them. The way Agatha handled this stuff seemed better (cleaner), and definitely more reusable than anything I had done.
The project I’m working on right now however is not a distributed app. So even though I have written a test for Agatha, up untill today I didn’t really have the time to get an actual implementation up and running.

So what’s changed ?

This.

My project gets audited by an external firm that the customer has hired specifically for this purpose. This is something some of my co-workers find a total nuisance, but I think getting a second opinion is almost always a pretty good idea. And in this case it has paid off.
I must admit that I almost always agree with their recommendations and that it has allowed me to introduce stuff, that without this external pressure would have been close to impossible.

Now, where using a very DDD-like approach (using our ‘service-layer’ as an anti-corruption layer ) and during the last code review one of the remarks that came back was : ‘Compile the interface definitions of your service-layer into a seperate dll so that it would become easier to switch from an in-process app to a distributed one.
I figured that even if we do that it would still be quite a task to migrate, and configure. Agatha promises (and as far as I can tell it delivers on this promise) an almost painless transition. So I decided to migrate our service layer to Agatha.

At first I just included the sample HelloWorld Request/Response into the project and tried to get it to compile and run.
It got that working in under five minutes.

As I was adding the first ‘real’ request, a translation of something that was allready there, it struck me that I didn’t have to configure the handler in the IoC container. I know it’s on the blog, and I’ve read it, but you only get to appreciate this once you’ve actually tried it.
My co-workers, most of whom had never even heard of an IoC container before, always forget about this and spend a lot of time trying to figure out what the hell is going on.

I remember once getting complaints from the guy sitting next to me, as his code compiled but he couldn’t start up the app. He forgot to register a new component in the service layer. As I pointed out the required line and explained why it needed to be there, he said : ‘What do you mean ? We actually have to type code to make this thing work?’. He was quite impressed with the way the IoC container handled things and removed a lot of infrastructure code, so that when he realized his mistake he started joking about the stuff you still had to pay attention too.

After implementing the first few Agatha handlers I turned to him and asked : ‘Do you remember your remark about having to register dependencies ?’.
He answered : ‘Yes, and because you ask I’m assuming we don’t have to do that anymore’.

That’s right. And it’s a time-saver.

When I read about this it looked good. After one day of using it, I’m impressed, … really impressed.

It doesn’t use a lot of fancy patterns, just some tried and tested basic OO stuff, and it forces you to abide by these rules.
And because you are using this, you end up thinking in a more OO way about the problem at hand, leading to far more cleaner code.

Need I say it again ?

I really like this lib.