Dependency Injection in Minimal APIs: A Love Letter with Caveats

Minimal APIs in modern .NET have grown up. What started as a lightweight alternative for small services has quietly become a first-class way to build serious production APIs. With .NET 10, that maturity is hard to ignore—and nowhere is that more apparent than in how dependency injection (DI) fits into the minimal API story.

This is not a tutorial. This is an opinion.

Minimal Doesn’t Mean Unsophisticated

When minimal APIs first appeared, many developers (myself included) mentally filed them under “quick demos” or “throwaway services.” The absence of controllers, filters, and layers of abstraction made them feel almost rebellious compared to traditional ASP.NET patterns.

Dependency injection challenged that assumption early on. The fact that you could inject services directly into endpoint delegates felt… strange. No constructors. No base classes. Just parameters.

At first glance, it looked like a shortcut.

In practice, it turned out to be a statement.

DI as an Explicit Contract

One of the most underappreciated aspects of DI in minimal APIs is how explicit it is. When dependencies are declared directly on an endpoint, they stop being hidden implementation details and start becoming part of the API’s narrative.

You don’t have to hunt through a controller’s constructor to understand what an endpoint needs. You don’t have to scan private fields. The dependencies are right there, in the open, sitting alongside route parameters and request data.

This visibility changes how you reason about your application. Endpoints feel more honest. They say, plainly, “this is what I depend on to exist.”

That kind of clarity is hard to give up once you get used to it.

The Trade-Off: Elegance vs. Sprawl

Of course, honesty can turn into oversharing.

As minimal APIs scale, dependency lists can grow. An endpoint with too many injected services starts to feel like a warning sign. The elegance of the model works best when each endpoint has a focused responsibility and a small dependency surface.

This isn’t a flaw of minimal APIs—it’s a forcing function.

If you find yourself injecting half your application into a single endpoint, the problem probably isn’t the DI system. It’s the design. Minimal APIs make that discomfort visible earlier, and that’s a good thing.

DI Without the Ceremony

Traditional ASP.NET patterns often encourage architectural ceremony. Controllers, services, interfaces, layers, and conventions all reinforce each other. That can be powerful, but it can also become noise.

Minimal APIs strip away that ceremony, and DI follows suit. You still get lifetimes, scopes, and container management, but without the sense that you’re participating in a framework ritual.

In .NET 10, this feels intentional rather than incidental. The platform seems comfortable letting you decide how much structure you want. DI is available, robust, and predictable—but it doesn’t demand a specific architectural shape.

That flexibility is empowering, but it also places more responsibility on the developer to make good decisions.

Testability Is Still a First-Class Citizen

A common fear with minimal APIs is that testability might suffer. Without controllers or clearly defined seams, where do you plug in mocks? Where do boundaries live?

In reality, DI remains the same quiet hero it has always been. Dependencies are still abstractions. Lifetimes still matter. The container still does its job.

What changes is that your seams are more intentional. Instead of being imposed by a framework pattern, they emerge from your design choices. That can feel uncomfortable if you’re used to the framework doing the thinking for you—but it often results in cleaner, more deliberate systems.

Opinionated Take: Minimal APIs Reward Discipline

Here’s the honest take: dependency injection in minimal APIs rewards disciplined teams and exposes undisciplined ones.

If you value clear boundaries, small services, and explicit dependencies, minimal APIs paired with DI feel liberating. If you rely on conventions to keep things from spiraling, the same tools can feel dangerously permissive.

.NET 10 doesn’t try to resolve that tension. It embraces it.

And maybe that’s the point.

Final Thoughts

Dependency injection in minimal C# APIs isn’t a compromise or a stripped-down version of “real” DI. It’s a different expression of the same idea—one that prioritizes clarity, explicitness, and developer intent over ceremony.

Minimal APIs aren’t about doing less work. They’re about doing only the work that matters.

And DI, quietly and reliably, is still right there at the center of it all.