Development with a Dot

Introduction Note: some people complained that what I actually called Dependency Injection is actually Inversion of Control. I won’t get into that fight, to me, Dependency Injection is a form of Inversion of Control. The  Strategy Pattern  (sometimes known as Policy) originated in the seminal book Design Patterns , by the Gang of Four. It is a behavioural design pattern  that allows picking a specific strategy at runtime. The concrete strategy to use can change dramatically how the application behaves. Quoting: instead of implementing a single algorithm directly, code receives runtime instructions as to which in a family of algorithms to use. Dependency Injection (DI), also known as Inversion of Control (IoC) - they’re not quite the same, but, for the purpose of this post, we can think of them as the same, even though this raises heated discussions - is built-in in .NET Core (now, .NET) since the start, and whilst we generally return the same implementation type ...

Note: this is an update of an old post that is no longer available from my old blog . Introduction Dependency Resolution (RS), Dependency Injection/Dependency Inversion (DI) and Inversion of Control (IoC) are hot topics for a long time. Basically all frameworks are aware of it, or offer some mechanisms to help implement it. It all started a long time ago, however, and things are slightly confusing at the moment – but will get better! In this post, I won’t go through all of the details of all dependency resolution libraries in existence, instead I will only focus on Microsoft libraries. Also, I will only talk about generic dependency resolution, leaving out more specialized usages, such as WCF , WF and SharePoint , which also use similar concepts. Origins It all started with the venerable IServiceProvider interface. It basically provided a single method, GetService , that gave answer to “get me an implementation for this type”. That was it, the single parameter was a Type , and the r...