Not Friendly with dynamic dbcontexts about dbcontextscope HOT 4 OPEN

We have a similar requirement - specifically a user logs into our asp.net mvc application and after authenticating them against a default database, user specific information determines which database they connect to the remainder of their session.

Things to consider when adding this functionality:

1. Would you want to prevent the connection string changing within a scope's lifetime?

e.g.

using (var dbContextScope1 = _dbContextScopeFactory.Create())
{
  var dbContext1 = dbContextScope.DbContexts.Get<UserManagementDbContext>(connectionString1);
    using (var dbContextScope2 = _dbContextScopeFactory.Create())
    {
      var dbContext2 = dbContextScope2.DbContexts.Get<UserManagementDbContext>(connectionString2);
    }
}

For our application I suspect it's preferable to force the connection string to stay constant for a given scope's lifetime.

2. Do you want to pass in the connection string every time you need to get DbContext?

It might be better to inject some configuration into the DBContextScopeFactory.

from dbcontextscope.

Looking more closely at the code, there's no need for changes. In order to support a dynamic connection string you can do the following.

1. Create a class DynamicDbContextFactory that implements the provided IDbContextFactory interface.
2. In the CreateDbContext method do whatever custom logic you need to return your DbContext initialised with the appropriate connection string.
3. When creating your DbContextScopeFactory ensure the dbContextFactory parameter of the constructor is set to an instance of DynamicDbContextFactory. I'll probably do this using my DI container.
4. To get a dbContextScope, just do the same as the examples e.g. var dbContextScope1 = _dbContextScopeFactory.Create()
5. To get a dbContext, just do the same as the examples e.g. var dbContext = dbContextScope.DbContexts.Get<UserManagementDbContext>();

Things to note:

• The DynamicDbContextFactory.CreateDbContext will only be called the first time a UserManagementDbContext is created within that scope. (see DbContextCollection.cs line 66) If the conditions that determine the connection string change after the first UserManagementDbContext is created but before the 2nd UserManagementDbContext is created (within the same dbContextScope's lifetime), the 2nd UserManagementDbContext will have the same connection string as the first one. This is a good thing.
• You don't need to pass in a connection string from all the code that uses the a DbContext.
• I haven't tested any of this but it sounds like it should work. I hope to implement it soon.

Thanks to mehdime for a great library and designing it in a way that it is able to be extended easily.

from dbcontextscope.

@ssippe did you have a chance to implement this feature? If you did would be able to share the code and your findings? Thank you!

from dbcontextscope.

No I didn't. One reason is that it hasn't been a priority for our business to refactor this into our system. The other reason is that I'm wavering in whether DbContextScope is the right way to go. Options I would consider in future projects are a) DbContextScope b) something along these lines https://www.reddit.com/r/dotnet/comments/2rcawo/managing_dbcontext_the_right_way_with_entity/cnfivdg or c) ditch EF for a micro-ORM like Dapper.

from dbcontextscope.