Online MongoDB courses

mongo-db-huge-logo_0This weekend, I completed the MongoDB (Python) developer and DBA courses, and I can really recommend them if you are interested in a gentle, yet fairly challenging, introduction to MongoDB.

The courses are run over ~7 weeks with instructional videos being released every week, and every week a couple of exercises must be completed in order to qualify for the final exam. Everything is online, and it’s completely free!

Next round begins on the 1st and 29th of April for the DEV and DBA courses respectively, and you can sign up at 10gen’s education site.

(PS: I got a 90% score on the DEV course and 96% on DBA – does that mean I’m more qualified to be a DBA than a developer..? I hope not!)

Bring back the types!

When you’re working with C# and reflection, you might end up in a situation where you have “lost” the type. For example, if you’ve deserialized an incoming message of some kind, you might have code that needs to do this:

Usually, when you want to do different stuff depending on the type of an object, you just call that object and let it do what it deems reasonable. That’s a good object-oriented way of delegating behavior to objects, totally anti-if campaign compliant and all. But in cases where the object you need to act upon is an incoming DTO, it’s usually not a good approach to put logic on that DTO.

This is a good time to do a “handler lookup” [1. I don’t know if there’s a better name for this pattern. I tried to ask Twitter, but I mostly got “it’s usually not a good idea to do that” – well, most patterns are usually not a good idea: all patterns should be applied only in cases where they make sense </stating-the-obvious>] in your IoC container for something that can handle an object of the given type. It goes like this: Given message: T, find handler: IHandle<T> and invoke handler with message.

In C#, that might look like this:

That’s not too bad I guess, but working at this untyped level for longer than this turns out to be cumbersome and hard to read and understand. It wouldn’t take more than a few lines more of invoking things via reflection before the dispatch of the message has turned into a mess! And then add the fact that exceptions thrown in method invocations made with reflection will be wrapped in TargetInvocationExceptions.

Consider this alternative approach where I use reflection to invoke a private generic method, closing it with the type of the message:

This way, the Dispatch method can have the bulk of the logic and it does not need to bother with the reflection API. Nifty!