在.NET Core WebAPI中修改Startup类ConfigureServices方法或通过IF-ELSE注册服务是否违反开闭原则？

Great question—let's break this down clearly, starting with what the Open/Closed Principle (OCP) actually requires, then why your proposed IF-ELSE approach still misses the mark, and finally better alternatives that align with OCP for your .NET Core Web API.

First, a quick refresher: OCP states that software entities (classes, methods, etc.) should be open for extension, but closed for modification. In your case, that means adding new services to your DI container shouldn’t require editing the existing ConfigureServices method.

Let’s be honest—if you’re adding new IF-ELSE branches to ConfigureServices every time you add a new service, you’re still modifying the original method. For example:

public void ConfigureServices(IServiceCollection services)
{
    // Existing core services
    services.AddControllers();
    services.AddDbContext<AppDbContext>();

    // New branch added every time you add a service
    if (someCondition)
    {
        services.AddScoped<IUserService, UserService>();
    }
    else if (anotherCondition)
    {
        services.AddScoped<IOrderService, OrderService>();
    }
    // Next service? Add another ELSE IF here (modifying existing code!)
}

This violates OCP because you’re changing the existing method’s code to add new functionality. The only way IF-ELSE wouldn’t violate OCP is if your conditions are based on dynamic, pluggable logic (like loading external assemblies or reading config to enable pre-built modules) where you don’t have to edit ConfigureServices to add new services. But that’s not the typical IF-ELSE approach most developers reach for.

Here are two practical, idiomatic ways to fix this in .NET Core:

1. Extension Method Pattern #

Wrap related service registrations in extension methods on IServiceCollection. This lets you keep ConfigureServices clean, and adding new services only requires creating a new extension method (no edits to existing code):

// UserServiceExtensions.cs
public static class UserServiceExtensions
{
    public static IServiceCollection AddUserServices(this IServiceCollection services)
    {
        services.AddScoped<IUserService, UserService>();
        // Add any related services here (repositories, etc.)
        return services;
    }
}

// OrderServiceExtensions.cs
public static class OrderServiceExtensions
{
    public static IServiceCollection AddOrderServices(this IServiceCollection services)
    {
        services.AddScoped<IOrderService, OrderService>();
        return services;
    }
}

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddDbContext<AppDbContext>();

    // Add new services by calling their extension methods (no edits to existing logic)
    services.AddUserServices();
    services.AddOrderServices();
}

2. Modular Service Registration #

For larger projects, create a module interface that handles service registration, then scan for and load these modules automatically. This way, adding a new service only requires creating a new module class—you never touch ConfigureServices again:

// IServiceModule.cs
public interface IServiceModule
{
    void RegisterServices(IServiceCollection services, IConfiguration configuration);
}

// UserServiceModule.cs
public class UserServiceModule : IServiceModule
{
    public void RegisterServices(IServiceCollection services, IConfiguration configuration)
    {
        services.AddScoped<IUserService, UserService>();
    }
}

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddDbContext<AppDbContext>();

    // Scan all assemblies for IServiceModule implementations and register their services
    var moduleTypes = Assembly.GetExecutingAssembly()
        .GetTypes()
        .Where(t => typeof(IServiceModule).IsAssignableFrom(t) && !t.IsAbstract);

    foreach (var moduleType in moduleTypes)
    {
        if (Activator.CreateInstance(moduleType) is IServiceModule module)
        {
            module.RegisterServices(services, Configuration);
        }
    }
}

Hardcoding IF-ELSE branches in ConfigureServices still violates OCP because you’re modifying existing code to add new features. Instead, use extension methods or modular registration to keep your ConfigureServices method closed for modification while being open to extension via new classes/methods.

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