Best of Dependency InjectionApril 2026

  1. 1
    Article
    Avatar of wearedotnetWe Are .NET·6w

    Abstractions That Heal, Abstractions That Harm

    Good abstractions reduce cognitive load and isolate change; harmful ones accumulate quietly and turn codebases into labyrinths. Using .NET and ASP.NET examples — interfaces, middleware, dependency injection, generic repositories, and Entity Framework — the post argues that abstractions should be introduced only when there are at least two concrete things to generalize across. Premature abstractions built on assumptions rather than evidence create the illusion of flexibility while actually constraining future change. Leaky abstractions like EF's lazy loading obscure rather than simplify. The quality of an abstraction reflects the depth of domain understanding behind it, and vague names like IServiceManager signal abstractions introduced before the domain was understood. The real danger is cumulative drift: individually reasonable layers that compound over time into a system no longer resembling the problem it solves.

  2. 2
    Article
    Avatar of milanjovanovicMilan Jovanović·5w

    Why I Switched to Primary Constructors for DI in C#

    C# 12 primary constructors can significantly reduce boilerplate in DI service classes by eliminating field declarations, constructor bodies, and assignments. The author shares their experience switching to primary constructors for ASP.NET Core services, explaining the key pitfall: parameters are captured as mutable variables, not readonly fields, meaning accidental reassignment compiles without warning. The recommended approach is to use primary constructors freely in DI service classes where accidental reassignment is unlikely, but fall back to traditional constructors for validation-heavy types, multiple constructor overloads, or classes with too many dependencies.

  3. 3
    Article
    Avatar of glwGolang Weekly·5w

    Golang Weekly Issue 597: April 17, 2026

    Golang Weekly Issue 597 curates several Go-focused articles and tools: a deep dive into the Go compiler internals to implement a conditional expression syntax; watgo, a zero-dependency pure Go WebAssembly toolkit for parsing WAT and creating WASM binaries; a guide on error translation in layered Go services using domain sentinels; and gontainer, a reflection-based dependency injection container from NVIDIA with no external dependencies.

  4. 4
    Article
    Avatar of wearedotnetWe Are .NET·7w

    ASP.NET Core: Why I Couldn’t Upgrade FluentValidation Past 11.4 in My Calzolari.Grpc.AspNetCore.Validation Package (and How I Finally Fixed It) – Anthony Giretti's .NET blog

    The author of the Calzolari.Grpc.AspNetCore.Validation package explains why upgrading FluentValidation past version 11.4 caused runtime crashes in ASP.NET Core gRPC applications. The root cause was FluentValidation 11.5+ making the IValidator<T> generic parameter contravariant (adding the 'in' keyword), which introduced new internal types that slipped through the package's name-based assembly scanning filter and got registered in the DI container as non-instantiable types. The fix involves five improvements to the AddValidators() method: excluding all types from the FluentValidation assembly itself, filtering out abstract classes, interfaces, and open generic types, adding try/catch around GetTypes() calls, and silently skipping irrelevant types instead of crashing. The updated package (version 10.1.0) is now available on NuGet.