The art of simplicity

As mentioned in a previous post , it is not that hard to start using dependency injection with Orleans. But what if you don’t want to use the built-in IoC container? To switch the IoC container instance you can call the UseServiceProviderFactory() method exposed by the SiloHostBuilder. Here is an example that uses StructureMap:

There are a lot of IoC containers out there in the .NET world. Most of them offer a comparable set of features but they all have there small differences. If you don’t know where to start when picking a container, have a look a the IoC Container Benchmark - Performance comparison article by Daniel Palme. He keeps an up-to-date list of benchmarks for the most popular IoC containers in .NET:

After upgrading to ASP.NET Core 2.0 the following code started to fail: In my HomeController, I have a this new piece of code added; Instead of getting my HomeController back with an instance of ILogger injected into it, I got the following error message: InvalidOperationException: Unable to resolve service for type 'Microsoft.Extensions.Logging.ILogger' while attempting to activate 'MyApp.Web.Controllers.HomeController'. This code worked before but refuses to work in ASP.NET Core 2.0. Someone mentioned me to try the following instead: And indeed this worked. It turns out that the ILogger interface is no longer registered in the IoC container. Instead you have to always resolve an ILogger<T>. I have no clue why they did this change…

StructureMap has an easy to use Registry DSL that can be used in a Registry class. By using (one or more) Registry classes you can group all your IoC plumbing together. Yesterday I had a situation where I wanted to use some object that was already registered in the IoC container in the registration of another class. This is possible by passing an IContext as a second parameter of the Use() method in the fluent API:

I’m a big fan of the Inversion of Control(IoC) pattern and how Dependency Injection(DI) frameworks can help you implement this pattern.  IoC was really a gamechanger to me and had a lot of impact on the way I build and architect my applications. Note: As I’m doing more and more functional programming, the need to use a DI framework is going away, but that’s something to discuss in another blog post Unfortunately something I see a lot in applications that use a DI framework is something I call “dependencies diarrhoea”. Let’s have a look at an example ASP.NET MVC controller to illustrate the problem: So what’s the problem here? Without even looking at the full implementation, it should be clear that this class is violating the ‘Single Responsibility Principle’ and is doing too much in one class. This not only makes it harder to reason about this class, but also makes it a lot harder to test. There is no fun in mocking out lots of dependencies just to test a small piece ...