I had some really great responses to my last post regarding some bad code I've shown to interviewees - pretty much everything I intended to be bad was spotted, as well as some interesting points I hadn't considered. Here's the code again along with the bad bits as I saw them, and then I'll go over the extra points raised in the comments.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/c63

You can learn a lot about good code from reading bad code, and at least something about how well someone codes from what they can tell you about bad code. With this in mind I handed a print out of some bad code to the latest prospective developers I've interviewed, to see what they made of it. I'll write another blog with the things I think is wrong with the code soon (there's quite a few of them), but it'd be very interesting to hear what people think is wrong with it before I do :)

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/c5e

I recently implemented Domain Events as a way of organising domain logic in our application; I really liked the way it worked out, so I wanted to share an overview of using Domain Events, as well as a class which automatically looks up all the available IDomainEventHandlers.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/c3P

I had a series of ASP.NET MVC controllers which took identifiers for various domain objects, loaded the objects, then passed them to ViewModels. In order to DRY out the code a bit I decided to factor the object-loading logic into a customer IValueProvider - it turned out pretty neat, and this is how I did it :)

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bdB