Instantiating EF Core DbContexts

Question

I've hit a strange problem With EF Core and I can't understand why ...

public class Startup
{
    static Config Config;

    public Startup(IConfiguration configuration)
    {
        Config = new Config();
        configuration.Bind(Config);
    }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddHttpContextAccessor();
        services.AddScoped(ctx => ctx.GetService<IHttpContextAccessor>()?.HttpContext);
        services.AddScoped(ctx => ctx.GetService<HttpContext>()?.Request);
        services.AddAuthInfo();
        services.AddSingleton(Config);

        services.AddDbContext<MembershipDataContext>(options => options.UseSqlServer(Config.Connections["Membership"]));
        services.AddDbContext<CoreDataContext>(options => options.UseSqlServer(Config.Connections["Core"]));
        services.AddDbContext<B2BDataContext>(options => options.UseSqlServer(Config.Connections["B2B"]));

        services.AddScoped<IMembershipDataContext, MembershipDataContext>();
        services.AddScoped<ICoreDataContext, CoreDataContext>();
        services.AddScoped<IB2BDataContext, B2BDataContext>();

        ...

... I extract custom auth information from each request and inject that in to my DbContexts.

Because of the init process I had to have a CTOR that accepts DbContextOptions so I simply added a second in the hope that it would call the right one ...

public EFDataContext(DbContextOptions options, IAuthInfo auth) : base(options) { AuthInfo = auth; }

public EFDataContext(DbContextOptions options) : base(options) { }

... At run time I see both CTOR's get hit several times inside a single request (not what I was expecting).

From other posts I note that many are saying I don't need the last three lines but removing them gives me exceptions telling me that other objects can no longer be constructed by DI.

So i'm confused ...

How do I get this working so that I can only construct 1 instance per request and only hit the CTOR with the most params when I do?

Answer 1

So I figured out if I modify factory code I can handle construction fine during "setup" scenarios for the db.

That then allowed me to have only a single CTOR on the context which is the one I need, The net result though is that I still need those extra lines or it fails with a DI exception ...

Unable to resolve service for type 'IMyContext' while attempting to activate 'SomeOther type'.

Then it clicked ... I don't ever ask for a "MyDbContext" I always ask for a "IMyDbContext" ... the extra lines are to map the interface calls in the container to the strongly typed context not to "re-add the context" to the container.

Answer 2

You should not be adding your contexts separately as scoped. That's the main source of your problem. When you use AddDbContext, it registers your DbContext-derived class. If you go on to request an interface, it has no idea how to satisfy that interface; it only knows how to satisfy the class. That's why you get exceptions, and it's why you felt the need to add the separate interface registrations. However, when you do that, you're requesting a different instance of your context class as it's an entirely different registration.

You don't need an interface for your context. I see people do this all the time, and it's just mind-numbing. There is absolutely zero point. The only thing that should be publicly accessible on your context should be your DbSet properties and built-in methods like Add, SaveChangesAsync, etc. If you want or need to generically work with the DbSets, there's Set<T> for that, so your context class can just be injected directly. Besides, it's not like your going to have multiple implementations of this context. It's a representation of your database, and as such, it is what is: one implementation for all time.

Additionally, you should not be injecting anything into your context other than DbContextOptions. If you need a service, DbContext has an internal service provider, and that's what you should be using, i.e. this.GetService<IAuthInfo>.

UPDATE

Based on the comment thread, I don't think I've been clear about what I was suggesting. You should have something like:

public interface IService
{
    void DoSomething();
}

Then, you'd create implementations of this for each of your providers, e.g. CosmosDbService, RavenDbService, EFService, etc. Then in the EFService, you'd inject your context class, not an interface:

public class EFService : IService
{
    private readonly MyDbContext _context;

    public EFService(MyDbContext context)
    {
        _context = context;
    }

    public void DoSomething()
    {
        // use _context
    }
}

In this way, the context is only there for the sake of EF. There's nothing extraneous added to it and no business logic exists there. Everywhere else in your code, you inject IService, and then you sub in the appropriate provider implementation (EF, Cosmos, Raven, etc.) via the DI container. All your business logic lives in the service class, as it should, and you don't need an interface for your context.

This also likely then means you also don't need extraneous services like your IAuthInfo in your context, either, meaning you can avoid the internal service provider. You'd instead inject IAuthInfo into your service class.

What you're doing now, is the exact opposite. You're fundamentally entangling your business logic with EF by making the context implement an interface that has nothing to do with its purpose: serving as a simple unit of work.