How can I avoid the Service Locator pattern when using Blazor Server and Entity Framework?

[kinetiq]

Anyone just starting out with Blazor Service Side with EF will come across this guidance:

https://docs.microsoft.com/en-us/aspnet/core/blazor/blazor-server-ef-core?view=aspnetcore-5.0

It makes two key points:

• Do not use DI to inject your DbContexts. Blazor pages are long-lived, and we need short-lived contexts. Long-lived contexts accumulate local data, which becomes stale and leads to unpredictable results.
• Instead, use the new DbContextFactory to materialize contexts as needed, and dispose the context when done.

It looks a bit like this:

using var db = DbContextFactory.CreateDbContext();
[...do work...]

And that works pretty well. When you have complex services, you might end up passing the context around as a parameter a bit more than is ideal, but it's fine.

So what's the problem?

I am integrating Blazor Server Side into an existing MVC project, and guess what? All those services inject the DbContext.

I wouldn't say it's a nightmare, but it's not a good dream either.

And because this is complicated, I will recap that this is not the way to go in Blazor Server Side. In MVC, this service is intended to be instantiated, used, and discarded at the speed of a request. In Blazor, the circuit could live for an hour or more, and the service would be along for the ride. The DbContext would go with it, accumulating stale data. On top of that the context would be Scoped, which exacerbates the problem even more because the same instance would likely be injected into multiple services.

So we don't want that.

What have you tried?

BlazorServiceAdapter (Service Locator)

My first attempt, where I attacked the core problem, looks a lot like Service Locator, which is often considered an anti-pattern. I thought I would include it here in case it's useful to someone. Feel free to skip ahead if you want to see my actual suggestion.

...Keeping in mind that my context is called KeystoneDb, and this does the job even for complex graphs of objects:

public class BlazorServiceAdapter 
{
    private readonly IServiceProvider ServiceProvider;

    /// <summary>
    /// Create an instance of TService, using the supplied instance of KeystoneDb rather than
    /// the one in the IoC container. Note that the service must have a constructor that takes KeystoneDb.
    /// If there are multiple constructors, you can decorate the one you want to use with
    /// [ActivatorUtilitiesConstructor].
    /// </summary>
    public TService GetService<TService>(KeystoneDb db)
    {
        return ActivatorUtilities.CreateInstance<TService>(ServiceProvider, db);
    }
    
    /// <summary>
    /// Shortcut for injecting services, using the Service Locator (anti) pattern. 
    /// </summary>
    public TService GetService<TService>()
    {
        return ServiceProvider.GetService<TService>();
    }
    
    public BlazorServiceAdapter(IServiceProvider serviceProvider)
    {
        ServiceProvider = serviceProvider;
    }        
}

In practice it might look like this:

using var db = DbContextFactory.CreateDbContext();
var myService = BlazorServiceAdapter.GetService<SomeService>(db); // this db instance is used, instead of the one in the IoC container!

myService.doGoodThings(); // the service does its work and then falls out of scope.

In a nut, this works but falls short due to the usual critiques of Service Locator: it's tough to test, it hides dependencies, etc.

BlazorAdapterFactory (a generic factory)

This is my current winner. I made a generic factory which can be injected like so:

public MyClass(BlazorAdapterFactory<SomeServiceService> createSomeServiceFactory) { ... }

And then used like this, which feels pretty good so far:

using var db = DbContextFactory.CreateDbContext();
var myService = CreateSomeServiceFactory.GetService(db); // this db instance is used, instead of the one in the IoC container!
... do work ...

The provided context will be automatically propagated throughout the dependency graph, thanks to ActivatorUtilities. I also wrote some reflection code to avoid obscure exceptions from ActivatorUtilities in the event that the service does not have a constructor with a parameter matching your context... If that happens, it will resolve the dependency. Maybe this is a mistake and I should be throwing a more friendly exception. Here's the code, and please keep in mind that these are alpha-quality bits:

public class BlazorAdapterFactory<TService> 
{
    private readonly IServiceProvider ServiceProvider;

    /// <summary>
    /// Create an instance of TService, using the supplied context rather than
    /// the one in the IoC container. If there are multiple constructors, you can decorate the one you want to use with
    /// [ActivatorUtilitiesConstructor].
    /// </summary>
    public TService GetService<TContext>(TContext db) where TContext : DbContext
    {
        var contextType = db.GetType();

        // If there is no constructor that takes our DbContext, ignore it and do normal
        // injection instead.
        if (!HasMatchingConstructor(contextType))
            return GetService(); 
        
        return ActivatorUtilities.CreateInstance<TService>(ServiceProvider, db);
    }

    /// <summary>
    /// If a DbContext is passed into ActivatorUtilities.CreateInstance but there is no matching
    /// constructor, it will crash. We want to be a little more friendly than that, so we only make
    /// that call if we find a suitable constructor. 
    /// </summary>
    private bool HasMatchingConstructor(Type contextType)
    {
        // First, check whether any constructor was decorated with [ActivatorUtilitiesConstructor].
        // If yes, that's the only constructor we care about. 
        var decoratedConstructor = GetConstructorWithActivatorAttribute();

        if (decoratedConstructor != null)
            return ConstructHasMatchingParameter(decoratedConstructor, contextType);

        // Next we look at any other Public constructors that may exist. Return whether
        // of them have a parameter that could work with our DbContext.
        var serviceType = typeof(TService);

        foreach (var constructor in serviceType.GetTypeInfo().DeclaredConstructors)
        {
            if (constructor.IsStatic || !constructor.IsPublic)
                continue;
            
            if (ConstructHasMatchingParameter(constructor, contextType))
                return true;
        }

        return false;
    }
    
    /// <summary>
    /// Returns a constructor that has [ActivatorUtilitiesConstructor], or null.
    /// </summary>
    private ConstructorInfo GetConstructorWithActivatorAttribute()
    {
        var serviceType = typeof(TService);

        return serviceType.GetConstructors(BindingFlags.Public)
            .FirstOrDefault(info => info
                .CustomAttributes
                .Any(x => x.AttributeType == typeof(ActivatorUtilitiesConstructorAttribute)));
    }        

    /// <summary>
    /// Returns true if the constructor has a parameter that contextType could belong to.
    /// </summary>
    private bool ConstructHasMatchingParameter(ConstructorInfo info, Type contextType)
    {
        return info
            .GetParameters()
            .Any(x => x.ParameterType.IsAssignableFrom(contextType));
    }
    
    /// <summary>
    /// Creates an instance of TService. Useful for services that do not use a DbContext,
    /// but where you still want to control the lifecycle. 
    /// </summary>
    private TService GetService() 
    {
        return ActivatorUtilities.CreateInstance<TService>(ServiceProvider);
    }         
    
    public BlazorAdapterFactory(IServiceProvider serviceProvider)
    {
        ServiceProvider = serviceProvider;
    }        
}

Wait, what is your question?

I started out looking for guidance on this, and I still am. I can't imagine I'm the first one here. I am wondering how people are solving this, if there's a best practice, if you see problems with this approach, etc.

And if not, I offer this code as a starting point.

@SteveSandersonMS

[kinetiq]

This has not exactly generated the discussion I was hoping for. Disappointing.

Well, it turns out this code has one, possibly two problems:

• If the dependency graph is a few levels deep, and the context is somewhere in there but not on the first level, ActivatorUtilities won't do the job at all, and there's obvious no way around it.
• Further, I think I may have been wrong about ActivatorUtilities propagating the substitution deeper than the initial set of dependencies. I was pretty confident when I wrote the post above, but I suspect I was mistaken. Doesn't matter, because...

I wrote a new version of ActivatorUtilities that does exactly what I want. That's right, punk. :) Took me half a day. You provide a context (and/or other services), and it resolves your service with those substitutions, throughout the dependency graph. If anyone is interested let me know, happy to share. Also refactored ActivatorUtilities quite a bit.

[davidfowl]

This is an interesting problem.

cc @ajcvickers

[ajcvickers]

@davidfowl Is there anything actionable here from the EF side?

[davidfowl]

Not specifically but the problem is once you remove DI from creating objects, the transitive closure needs to follow that same pattern. That seems to be the case here with the DbContextFactory.

[kinetiq]

@ajcvickers @davidfowl Well, the guidance states that you should not be injecting EF contexts at all right now, which is fine for new code.

However, I have hundreds of thousands of lines of MVC code I'm trying to interoperate with, and Blazor is quite close to being able to do that. The barrier is injected contexts. Having a hierarchy three levels deep where contexts are injected at all three levels is normal, and there is currently no way to make that work well using Blazor.

However, my latest solution (which is not what I describe above) seems to work:

using var db = DbContextFactory.CreateDbContext();
var myService = CreateSomeServiceFactory.GetService(db);

This recurses through the dependency hierarchy much as Core DI would. However, any time an assignable context is found as a parameter, rather than injecting it in the normal DI way, I inject the provided db instance using modified ServiceUtilities.CreateInstance code. Anything that has no assignable DbContext among its children is instantiated via ServiceProvider.

I am thinking of releasing this as open source and hoping to get thoughts from high level folks about whether there's a better way. I was on Blazor Train awhile back talking about how easy it is to using Blazor with MVC in the same project, and now I feel a responsibility to make sure that's actually true.