The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,224 other subscribers

Archive for February 4th, 2015

On my research list: NCrunch for Visual Studio

Posted by jpluimers on 2015/02/04

Thanks Stefan Glienke for pointing me to NCrunch for Visual Studio:

NCrunch is an automated concurrent testing tool for Visual Studio.

It intelligently runs automated tests so that you don’t have to, and gives you a huge amount of useful information about your tested code, such as code coverage and performance metrics, inline in your IDE while you type.


Posted in .NET, .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0, .NET 4.5, C#, C# 2.0, C# 3.0, C# 4.0, C# 5.0, C# 6 (Roslyn), Development, Software Development | Leave a Comment »

Inversion of Control explained in a few sencences

Posted by jpluimers on 2015/02/04

One of the difficult things with design principles like Inversion of Control, is that virtual all descriptions are lengthy and therefore difficult to grasp.

I’ve been using interfaces to decouple software for a long time, but it also took me a while to get IoC, especially the Inversion part.

The first time I got the Inversion principle was when reading the answer  by Derek Greer to What is the Dependency Inversion Principle and why is it important? and especially the summary in the comment by Patrick McElhaney:

The difference between MyService → [ILogger ⇐ Logger] and [MyService → IMyServiceLogger] ⇐ Logger is subtle but important.

A similar explanation can be found in the somewhat longer, but very well written articles Dependency Injection Is NOT The Same As The Dependency Inversion Principle and A curry of Dependency Inversion Principle (DIP), Inversion of Control (IoC), Dependency Injection (DI) and IoC Container.

The whole point of the “Inversion” part is twofold:

  1. you declare the interface (ILogger) between a service user (MyService) and a provider (Logger) close to the user.
  2. you do this so that MyService does not need to change when you switch to a different provider: a new Logger provider needs to implement the ILogger interface too, even if it is from a completely different source or vendor.

Keeping that interface stable has the consequence that there will be more work on the provider side, for instance by using the adapter pattern to map the provider to the interface.

Knowing this, it was far easier to understand these articles that are often regarded as the fundamental ones, most from Martin Fowler’s site:


Posted in Dependency Injection, Design Patterns, Development, Inversion of Control / IoC, Software Development | 1 Comment »

%d bloggers like this: