依赖注入（DI）容器应设为全局吗？跨类库访问方案咨询

Great question—this is a super common sticking point when working with dependency injection across multiple class libraries, and the answer hinges on balancing clean architecture with practicality. Let’s break down your options and the best practices:

Avoid Static/Global Containers (Almost Always) #

First off, let’s get this out of the way: using a static or global DI container is generally considered an anti-pattern (specifically the Service Locator anti-pattern), and here’s why:

• Tight coupling: Your classes end up depending on the container itself instead of the specific dependencies they need. This violates the Dependency Inversion Principle, making your code harder to maintain and refactor.
• Hidden dependencies: When you pull services directly from a global container, other developers (or future you) can’t immediately see what a class needs just by looking at its constructor. You have to dig into the code to find out, which adds unnecessary friction.
• Testing headaches: Unit testing becomes way harder. Instead of easily mocking dependencies and passing them into the constructor, you have to configure the global container for every test, leading to brittle test suites.

The Preferred Approach: Constructor Injection (No Container Needed in Class Libraries) #

The cleanest way to handle cross-class-library calls is to keep your class libraries completely unaware of the DI container. Here’s how it works:

1. Define dependencies explicitly in your class library: Any class in your library should declare its required dependencies via its constructor, just like you would in your main application. For example:

   // In your class library (e.g., PaymentProcessing.Lib)
   public class PaymentProcessor
   {
       private readonly IPaymentGateway _gateway;
   
       // Declare dependency via constructor
       public PaymentProcessor(IPaymentGateway gateway)
       {
           _gateway = gateway;
       }
   
       public async Task ProcessPayment(decimal amount)
       {
           await _gateway.Charge(amount);
       }
   }
   
   public interface IPaymentGateway
   {
       Task Charge(decimal amount);
   }
   

2. Register class library services in your main application: The DI container should only be configured in your startup project (the one that boots your app, like an ASP.NET Core web app or console app). Here, you register both the services from your class libraries and your application-specific implementations:

   // In your main app's startup/config
   var builder = WebApplication.CreateBuilder(args);
   
   // Register the class library's service and its implementation
   builder.Services.AddScoped<IPaymentGateway, StripePaymentGateway>();
   builder.Services.AddScoped<PaymentProcessor>();
   

3. Use the dependency normally: When you need to use PaymentProcessor in another part of your app (even across class libraries), you just inject it into the constructor of the calling class—no need to reference the container at all. The container handles resolving all nested dependencies automatically.

When You Might Need to Access the Container (Last Resort) #

There are rare edge cases where constructor injection isn’t feasible—like in legacy code, certain ASP.NET Core filters, or static utility classes. In these scenarios:

• Don’t create a custom global container. Instead, use the framework-provided service provider (like IServiceProvider in .NET) if available.
• Limit this pattern to small, isolated parts of your codebase. Never use it in core business logic, as it will undermine the benefits of DI.

Final Takeaway #

Stick to constructor injection whenever possible. Your class libraries should focus on defining their dependencies and business logic, not on how those dependencies are resolved. The main application’s DI container is responsible for wiring everything together, which keeps your code decoupled, testable, and easy to maintain.

内容的提问来源于stack exchange，提问作者Mayur