Efcore: Commands: Flow info into IDbContextFactory

Created on 1 Jun 2016  路  7Comments  路  Source: dotnet/efcore

There are two pieces of information that should somehow be flowed into IDbContextFactory so that users can properly implement it in a way that works well with the commands:

  • Environment
  • Startup project directory
type-bug

Most helpful comment

@jammerware IDbContextFactory<OurContext> is designed to be a brute force way to tell EF Tooling (and other design time things) how to create your context without using DI etc. It's not really designed to be registered in DI and used at runtime. Of course, you can reuse it for that, but it probably makes more sense to define your own factory.

All 7 comments

Would these be flown through constructor parameters? Otherwise if we think our understanding of the requirements is going to evolve in the next few months (i.e. if the interface needs to change), should we more aggressively move stuff like this to our tooling packages before we RTM our runtime?

We talked about just adding a dictionary (overload?) to the Create method that could grow over time as needed.

I guess that works. It doesn't make it easy to discover what arguments the implementation should handle though. Would an options class work?

I like the idea of using an options class. That way it could be inject into other places in the future.

This change has caused us to wonder if maybe we've been using IDbContextFactory incorrectly.

We have a custom context factory that implements IDbContextFactory<OurContext> that we inject into classes that need database access (repositories, for example). Then, when we need a context, we just create one from the factory:

using(var context = contextFactory.Create()) {
    // do databasey stuff here
}

Since the interface no longer enforces a parameterless Create method, our code broke with RTM. Should we be registering a DbContextFactoryOptions object with our IoC container? Are we managing our context factory incorrectly?

@jammerware IDbContextFactory<OurContext> is designed to be a brute force way to tell EF Tooling (and other design time things) how to create your context without using DI etc. It's not really designed to be registered in DI and used at runtime. Of course, you can reuse it for that, but it probably makes more sense to define your own factory.

@rowanmiller Understood. Thanks for the clarification!

Was this page helpful?
0 / 5 - 0 ratings