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 ...

Introduction Multitenancy is a hot topic, which I covered a few times on my old blog. I won't dwell on its concepts, but, instead, I will present ways to apply multitenancy to EF Core. When it comes to data, multitenancy means that we should only retrieve data for the current tenant. I will present three ways to obtain the tenant id from inside of a  DbContext , which can then be used to set up query filters, connection strings, or mapping configuration. Multitenancy in Databases So, as I blogged before, there are essentially three strategies for applying multitenancy to databases: Using a tenant column on tenant-aware tables and filter by it Using a different schema, meaning, tenant-aware tables will be duplicated in different schemas and for each request, one schema will be used Using different databases, one for each tenant, and, for each request, pick the right connection string There are obviously pros and cons to each approach, but I won't go through them now. Instead,...

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...

Introduction Dependency Injection  (DI) is a critical part of .NET since the .NET Core days. A simple, although powerful, DI container is included out of the box, and ASP.NET Core makes heavy use of it . I already wrote about DI in .NET a few times: .NET 8 Dependency Injection Changes: Keyed Services ASP.NET Core Inversion of Control and Dependency Injection The Evolution of .NET Dependency Resolution Dependency Injection Lifetime Validation .NET Core Service Provider Gotchas and Less-Known Features An Extended Service Provider for .NET This time I want to highlight something that people may not be aware of, even though I already mentioned it in one of my posts. Retrieving Services As you know, the DI is represented by an instance of IServiceProvider . When we want to retrieve a service we call  GetService , passing it a Type , for a dynamic call, or  GetService<T> , for a strongly-typed version, which just calls the other one with a cast. Now, if the service repre...

Introduction In the past, I already wrote about the .NET service provider, including some gotchas ,  recent changes , and its history . Now, I'm going to talk about something different. There are multiple open tickets , which include some features, for the .NET service provider. Having experienced some issues myself, I decided to augment the built-in provider with some features that I find useful, so here we are. Problems With this implementation, I wanted to overcome a few issues: Being able to provide my own service instance, at runtime (dynamically); note that this is already possible, as you can specify a factory method that will be called when the service is requested, but I wanted a different thing, more dynamic Being able to hook into the service provider and do things to services once they are obtained; this allows, for example, setting property values or doing any kind of instantiation Let's see how this works, enter the ExtendedServiceProvider ! The ExtendedServicePro...