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.

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

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.
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.
If a microservice needs more than one bounded context, it's either not truly a microservice, or your contexts are not bounded appropriately.
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.
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.
|
0

Just do it for each context:

 services.AddScoped<YourContext>(s => { var builder = new DbContextOptionsBuilder().UseSqlServer("ConnectionString"); return new YourContext(builder.Options); });
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.