Change dependency resolution for specific scope only

Question

I have one dependency registered as follows:

interface IDependency { }

class DependencyImpl : IDependency { }

Startup:

services.AddScoped<IDependency, DependencyImpl>();

This works as intendended as I do want to reuse the same instance in the scope of my Web API requests.

However, in one background service, I'd like to tell which instance it will resolve to:

class MyBackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory; // set in ctor

    public void DoStuff()
    {
        var itens = GetItens();

        var dependencyInstance = new DependencyImpl();

        Parallel.ForEach(itens, (item) =>
        {
             using(var scope = _scopeFactory.CreateScope())
             {
                 scope.SwapDependencyForThisScopeOnly<IDependency>( () => dependencyInstance ); // something like this

                 var someOtherService = scope.ServiceProvider.GetRequiredService<ItemService(); // resolve subsequent services with provided dependencyInstance
                 someOtherService.Process(item);
             }
        });
    }

}

I can't reuse the same Scope because ItemService (and/or it's dependencies) uses other scoped services that can't be shared. Neither I want to replace dependency resolution for the entire application.

Is it possible to do what I want here? Does it make sense?

I'm using dotnet core 2.2 with default IoC container for that matters.

Edit in reply to @Steven: DependencyImpl contains configurations for how an item will be processed. One of those includes an relatively expensive query. DependencyImpl is also injected more than once in the graph. So, currently, it reads the configuration once, cache them in private properties, and use the cached version on subsequent reads. Because I know I'll be reusing the same configuration for all itens here, I'd like to avoid reading the configuration again for each parallel execution.

My real-world dependency is more similar to this:

interface IDependency 
{ 
    Task<Configuration> GetConfigurationAsync();
}

class DependencyImpl : IDependency 
{ 
    private readonly Configuration _configuration;
    private readonly DbContext _dbContext;

    ctor(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async  Task<Configuration> GetConfigurationAsync()
    {
         if(_configuration is null)
         {
              // read configurations
         }

         return _configuration;
    }
}

I understand that, as is, my class is not thread-safe. I'd have to force a read at the start and/or add some thread safety here.

Also, those processings used to happen during the lifetime of a web request, and the background service is the new stuff. I'd prefer to change as little of existing code as possible, because there are few tests in place, and of course time constraints from the powers-that-be.

Answer 1

In general, it is not a good idea to change the structure of the registered object graphs while the application is running. Not only is this hard to achieve with most containers, it is prone to suble problems that are hard to detect. I, therefore, suggest a small change in your design that change circumvents the problem you are facing.

Instead of trying to change the dependency as a whole, instead pre-populate an existing dependency with the data loaded on a a different thread.

This can be done using the following abstraction/implementation pair:

public interface IConfigurationProvider
{
    Task<Configuration> GetConfigurationAsync();
}

public sealed class DatabaseConfigurationProvider : IConfigurationProvider
{
    private readonly DbContext _dbContext;

    public DatabaseConfigurationProvider(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Configuration Configuration { get; set; }

    public async Task<Configuration> GetConfigurationAsync()
    {
         if (Configuration is null)
         {
             await // read configurations
         }

         return Configuration;
    }
}

Notice the public Configuration on the DatabaseConfigurationProvider implementation, which is not on the IConfigurationProvider interface.

This is the core of the solution I'm presenting. Allow your Composition Root to set the value, without polluting your application abstractions, as application code doesn't need to overwrite the Configuration object; only the Composition Root needs to.

With this abstraction/implementation pair, the background service can look like this:

class MyBackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory; // set in ctor

    public Task DoStuff()
    {
        var itens = GetItens();

        // Create a scope for the root operation.
        using (var scope = _scopeFactory.CreateScope())
        {
            // Resolve the IConfigurationProvider first to load
            // the configuration once eagerly.
            var provider = scope.ServiceProvider
                .GetRequiredService<IConfigurationProvider>();

            var configuration = await provider.GetConfigurationAsync();

            Parallel.ForEach(itens, (item) => Process(configuration, item));
        }
    }

    private void Process(Configuration configuration, Item item)
    {
        // Create a new scope per thread
        using (var scope = _scopeFactory.CreateScope())
        {
            // Request the configuration implementation that allows
            // setting the configuration.
            var provider = scope.ServiceProvider
                .GetRequiredService<DatabaseConfigurationProvider>();

            // Set the configuration object for the duration of the scope
            provider.Configuration = configuration;

            // Resolve an object graph that depends on IConfigurationProvider.
            var service = scope.ServiceProvider.GetRequiredService<ItemService>();

            service.Process(item);
        }    
    }
}

To pull this off, you need the following DI configuration:

services.AddScoped<DatabaseConfigurationProvider>();
services.AddScoped<IConfigurationProvider>(
    p => p.GetRequiredService<DatabaseConfigurationProvider>());

This previous configuration registers DatabaseConfigurationProvider twice: once for its concrete type, once for its interface. The interface registration forwards the call and resolves the concrete type directly. This is a special 'trick' you have to apply when working with the MS.DI container, to prevent getting two separate DatabaseConfigurationProvider instances inside a single scope. That would completely defeat the correctness of this implementation.

Answer 2

Make an interface that extends IDependency and only applies to the faster implementation that you need to request, e.g., IFasterDependency. Then make a registration for IFasterDependency. That way your faster class is still an IDependency object and you won't disrupt too much existing code, but you can now request it freely.

public interface IDependency
{
    // Actual, useful interface definition
}

public interface IFasterDependency : IDependency
{
    // You don't actually have to define anything here
}

public class SlowClass : IDependency
{

}

// FasterClass is now a IDependencyObject, but has its own interface 
// so you can register it in your dependency injection
public class FasterClass : IFasterDependency
{

}