IImageProviders created as singletons? about imagesharp.web HOT 5 CLOSED

Sorry to abandon my question like this, but I solved the original issue by manually requesting the db-context (via HttpContext):

public Task<IImageResolver> GetAsync(HttpContext context)
{
    ...

    using (var dbContext = context.RequestServices.GetService<ApplicationDbContext>())
    {
        ...
    }
}

from imagesharp.web.

Hi @vyliniem

Yeah, that's a bit of a pickle for you. The reason we do that is to ensure that we do not want to instantiate complex members on each requests. For example in this Azure Blob Provider we take advantage of the singleton scoping to reuse the CloudBlobClient. This dramatically reduces the overhead for us.

One workaround you could do for now is to use the service locator (not great but will work) inside your custom provider to return the DbContext.

In the interim I'm going to have a look to see If I can refactor this to scope the providers (cache also) to the request scope to allow more flexibility of injection but keep the performance by injecting singleton configuration types.

@sebastienros Would changing the scope upset things in Orchard or would that be ok?

from imagesharp.web.

Going scoped should never be an issue. If you need to hold state across instances the user can always create a separate instance that is registered as Singleton and resolve it in the scoped service.

from imagesharp.web.

@vyliniem just for reference you could look at this section in the .net core docs: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2#call-services-from-main

You could inject the IServiceScopeFactory into your IImageProvider and create a scope and resolve your ApplicationDbContext inside that scope as shown in the example in the link above.

from imagesharp.web.

@sebastienros Just to clarify, are you saying I should refactor the processors to allow efficient use in a scoped lifetime?

from imagesharp.web.