I’m a big fan of strong typing. If you can leverage the compiler to give you an error (or warning) before you deploy code, all the better. That means you won’t, ideally, push a bug into the field. So I have a big problem with frameworks and libraries that rely on dynamic objects, or even worse, stringly typing thing. Don’t get me wrong, sometimes dynamics are the only way to solve the problem, but whenever I run into one I’m always afraid that I’m going to get a runtime error since I don’t really know what I’m acting on till later.
In this post, I’m going to discuss strongly typing signalR. For the impatient, I have a working demo up, as well as the code posted on my github.
That said, I’ve written about signalR before so I won’t rehash that, but signalR uses dynamic objects heavily to … Read more
In a production application you frequently can find yourself working with objects that have a large accessor chain like
But when you want to program defensively you need to always do null checks on any reference type. So your accessing chain looks more like this instead
if (student.School != null)
if (student.School.District != null)
if (student.School.District.Street != null)
s += student.School.District.Street.Name;
Which sucks. Especially since its easy to forget to add a null check, and not to mention it clutters the code up. Even if you used an option type, you still have to check if it’s something or if its nothing, and dealing with huge option chains is just as annoying.
One solution is to use the maybe monad, which can be implemented using extension methods and lambdas. While this is certainly better, it can still can get unwieldy.
What I … Read more