Commands: Flow info into IDbContextFactory

[bricelam]

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

[divega]

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?

[bricelam]

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

[divega]

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

[bricelam]

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

[jammerware]

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?