2

I am using .Net core 2.1 + EF Core to build WebApi. Based on this discussion: Entity Framework: One Database, Multiple DbContexts. Is this a bad idea? and the bounded context concept from DDD I want to create multiple DbContext for different functionalities in my app. There are several resources provided by Julie Lerman on PluralSight.com but non of those cover dependency injections in .net core. So far I did something like this:

var connectionString = Configuration.GetConnectionString("DatabaseName");
 
services.AddDbContext<DatabaseContext>(options =>
    options.UseSqlServer(connectionString, optionsBuilder =>
        optionsBuilder.MigrationsAssembly("Database.Migrations")));
services.AddDbContext<ProductContext>(options =>
    options.UseSqlServer(connectionString));
services.AddDbContext<CountryContext>(options =>
    options.UseSqlServer(connectionString));

here DatabaseContext is a context used for EF Core migrations (does not actually query the data) and ProductContext and CountryContext are two of the contexts I use for my data manipulation. My questions are:

  • Is this a right way to do it? It feels a bit odd to re-use same connection string
  • It feels like I would be using 2 separete connections (and this will grow), could this cause some data access issues in the future, locks, concurency, etc?

UPDATE (2022-11-11)

I have been using this for few years now. Did not had any issues related to DB connection so far. Planning to use this this approach in future projects as well.

Ramūnas
  • 1,494
  • 18
  • 37

2 Answers2

2

The concept of having bounded contexts is fine, per se. It's based on the idea that the particular application shouldn't have access to things it doesn't need. Personally, I think it's a tad bit of overkill, but reasonable people can disagree on the issue.

However, what you have here, is simply wrong. If your application needs access to all these bounded contexts, it makes no sense to have them. Just feed it one context with all the access it needs. Yes, each context will have a separate connection, so yes, you will likely have multiple connections in play servicing requests. Again, this is why it makes no sense to divy out your contexts in this scenario.

If, however, you were to take a microservice architecture approach, where each microservice dealt with one discreet unit of functionality, and you wanted to be a purist about it, employing bounded contexts would make sense, but in a monolithic app, it does not.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • The above is an example and also very early stage of the project, but the requirement stands that it would be orientied in microservices architecture, hence the approach I am trying to take. – Ramūnas Sep 11 '18 at 13:39
  • Well, a microservice approach negates your two questions: 1) You're not "re-using the same connection string", because each service would only have its one context. 2) You won't have multiple connections, because, again, each service would have just its one context. – Chris Pratt Sep 11 '18 at 13:46
  • If a microservice needs more than one bounded context, it's either not truly a microservice, or your contexts are not bounded appropriately. – Chris Pratt Sep 11 '18 at 13:47
  • 2
    I disagree with "what you have here, is simply wrong" If you're of the _opinion_ that monolithic is bad, and microservices is good, that's fine, but it's not wrong. There's nothing wrong with a monolithic app, and microservices architecture has it's detractors as well. Both microservices and DDD bounded contexts are there to solve the problem of trying to maintain a unified model across a large domain, but are not equivalent. – Adam Vincent Sep 11 '18 at 14:05
  • I never said monolithic is wrong. However, employing multiple bounded contexts in one monolithic app *is* wrong. There's no point, because the app has access to everything *anyways*. All you're doing is just requiring more database connections to the same database. Bounded contexts only make sense if the application's domain is bounded as well. – Chris Pratt Sep 11 '18 at 14:11
  • To be more clear. It has nothing to do with monolithic vs microservices. You could have a monolithic app that only works with a subset of the backing database. In which case, having a bounded context for that subset might make sense, but you would still have *one* context. If you're adding in all the bounded contexts into one app, nothing is truly "bounded". – Chris Pratt Sep 11 '18 at 14:13
  • I do agree with @ChrisPratt that your bounded contexts may not be defined properly. You don't want a bounded context for every class, nor do you want a context for every use case. What you're looking for is a logical group of use cases. Check out the image on [this link](https://martinfowler.com/bliki/BoundedContext.html) and take a look at the image on how some tables are unique to a context, and some are shared with another context. Also, it's never a bad idea to read some martin fowler. =D – Adam Vincent Sep 11 '18 at 14:18
  • I'd be open to further debate @ChrisPratt, I'm on chat.stackoverflow. – Adam Vincent Sep 11 '18 at 14:24
  • @AdamVincent the image is what I bassically will be aiming to do in my app, it is just a beginning now, and I need to start from somewhere, both contexts would grow possible having multiple sets of entities. But I want to get things clear before investing into chosen strategy. – Ramūnas Sep 11 '18 at 14:52
0

Just do it for each context:

        services.AddScoped<YourContext>(s =>
        {
            var builder = new 
            DbContextOptionsBuilder().UseSqlServer("ConnectionString");
            return new YourContext(builder.Options);
        });
Diogo de Freitas nunes
  • 21
  • 1