Trouble in resolving IServiceProvider directly into the base class ASP.NET Core. I don't want to pass it through constructors of any child class

Question

I have a classes tree having one being inheriting the other. All these base classes have different types of functionalities. So the inheriting class can choose which one to go for. Functionalities are move from base class to upwards. The base functionality of these classes requires IServiceProvider to be resolved.

The first solution which I don't like is passing IServiceProvider into the handler class which moves from one base to the next and so on.

The second one is what I am looking for. I looking for a workaround that I should be able to create instances of my handler classes without parameters and the base class itself should resolve IServiceProvider whenever required.

I could not find a solution to this till now.

Code example to make the question meaningful I am adding some code skeleton.

abstract class Root<ResultType, DbClass>
    where ResultType : class
    where DbClass : class
{
    private DbContext ent;
    abstract ResultType DefineHowToCreateResult(DbClass inputClass);

    IEnumerable<ResultType> GetAll()
    {
        // This class itself should be able to resolve the context. So everytime
        // it should not expect it to come all the way from child
        ent = ResolveContext<DbContext>();
        return DefineHowToCreateResult(ent.DbClass());
    }

    DbClass AddNew(DbClass inputPara)
    {
        // This class itself should be able to resolve the context. So everytime
        // it should not expect it to come all the way from child
        ent = ResolveContext<DbContext>();
        ent.AddNew(inputPara);
        return DbClass;
    }
}

Some functionalities come under the scope of this intermediate class. But it is never supposed to do GetAll() or AddNew() kind of functionalities. Because it is supposed to be handled by the Root class.

abstract class IntermediatRoot<ResultType, DbClass, InterMediatPara>
    : Root<ResultType, DbClass>
    where ResultType : class
    where DbClass : class
    where InterMediatPara : class
{
    ResultType PerformInterMediatWork()
    {
        var allData = GetAll();
        //------
        //------
        //------
        //------
        //------
        return ResultType;
    }
}

I simply want it to be a parameterless constructor and don't want to take IServiceProvider all the way down. Because ultimately it is required on Root class and I want that root class to be able to resolve the perform what I want. It would make that class a little bit independent and self-responsible for the scope of work given to it.

internal class HandlerClass : IntermediatRoot<H1, H2, H3>
{
    private override H1 DefineHowToCreateResult(H2 inputClass)
    {
        //------
        //------
        //------
        //------
    }
}
class H1 { }
class H2 { }
class H3 { }

Answer 1

Before anything furthur, i must say this first... what's so wrong with passing IServiceProvider along the child class in the hierarchy ? If the child class doesn't make use of it, then just less it pass through, otherwise, create a private readonly property should be fine. Since the DI will automatically provide the right scope of which IServiceProvider you should be use.

And if you want it so bad... create an instance which hold the service provider like

public class ServiceProviderContainer : IDisposable
    {
        private static IHttpContextAccessor _httpContextAccessor;
        private static readonly ConcurrentDictionary<string, IServiceProvider> ServiceProviderContainers = new();

        public ServiceProviderContainer(IServiceProvider serviceProvider, IHttpContextAccessor httpContextAccessor)
        {
            _httpContextAccessor = httpContextAccessor;
            if (!string.IsNullOrEmpty(httpContextAccessor.HttpContext?.TraceIdentifier))
            {
                ServiceProviderContainers.TryAdd(httpContextAccessor.HttpContext?.TraceIdentifier, serviceProvider);
            }
        }

        public static IServiceProvider ResolveCommonServiceProvider() =>
            _httpContextAccessor.HttpContext?.TraceIdentifier != null &&
            ServiceProviderContainers.TryGetValue(_httpContextAccessor.HttpContext.TraceIdentifier,
                out var serviceProvider)
                ? serviceProvider
                : throw new InvalidOperationException(
                    $"failed to get the Service Provider. Current trace Id: {_httpContextAccessor.HttpContext?.TraceIdentifier}");

        public void Dispose()
        {
            if (!string.IsNullOrEmpty(_httpContextAccessor.HttpContext?.TraceIdentifier))
            {
                ServiceProviderContainers.TryRemove(_httpContextAccessor.HttpContext.TraceIdentifier, out _);
            }
        }
    }

Register it as scope services.AddScoped<ServiceProviderContainer>(); - And this is the only life cycle you want to register something like Service provider!

If you already have a middleware upper your execution logic, put it there to ensure it get created every http request:

public class SomeUpperMiddleware
    {
        public SomeUpperMiddleware(ServiceProviderContainer container)
        {
        }
    }

Then now, feel free to use it anywhere in your application:

var container = ServiceProviderContainer.ResolveCommonServiceProvider();
var logger = container.GetRequiredService<ILogger<ProductController>>();

But let me insist again, this approach should be avoid cause it make the scope of IServiceProvider dusky.