Steve Wilkes' blog on .NET, Agile, TDD, design patterns and all that jazz
My current pet project uses Node, Angular and TypeScript. This is my first time working with Node or Angular and the differences in the way they approach Dependency Injection led to this post.
I've recently been working with a number of VB6 systems which use C# .NET components via COM, and wanted to keep the same sort of organisational structures and patterns in the C# part of the application as I would if it was a standard MVC app or WCF service - namely, using Dependency Injection to plug the various C# classes together. This is easier said than done with COM, but here's an approach I've used to achieve it.
I recently reused my generic, disposable WCF service client, and made some changes to make it simpler to use and easier to unit test. Here's what I did.
For the last two years, I’ve ordered the Nimble Pros Software Craftsmanship calendars, which use ‘motivational poster’ style pictures to depict various software practices and principles worth keeping in mind. Here’s one of the walls at work, where I’ve got the calendars cut up and displayed for easy reference: I like being able to point to a principle when its use pops up, and they provide a nice illustration of things everyone should be aware of. I’ll be following this up with a post on each month’s ......
The ViewModels in my current project had got quite complex; as well as properties copied from model objects, they increasingly had flags used by Views to know whether to render links or sub-sections. The logic which set these properties was bloating Controllers, so I factored it out into objects which populate all non-editable properties of a ViewModel; ViewModelBuilders. Here's how :)
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.
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 :)
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.
The application I'm currently working on performs user authorization using authorization objects injected into Service Layer methods using Unity Interface Interception. There's quite a lot of these objects, which means quite a lot of configuration, so I decided I'd make them configure themselves :)
Yesterday I did my first grok talk - it was on Unity Interception at Dot Net Dev Net in Bristol, UK. It went ok! The feedback was that the content was very good but the presentation could have been a bit better, which is very possibly the story of my programming life :) For posterity, I've put the content on Github.
Full Dependency Injection (DI) Archive