CODEWITHSUNDEEP
entity-frameworkasp.net-coreentity-framework-core.net-core
Bintang Chester
Bintang Chester

Reputation: 113

EntityFrameworkCore quite a dbcontext or should Separating DbContext In .Net Core Like Bounded Context For Getting Performance

in EntityFramework old version if I have a table DbSet more than 50, I would definitely separating using BoundedContext concept, because most of the tips and tricks that I got from some blog site, now my question how in .net core if I have 100 tables, whether EntityFrameworkCore can handle 100 table or more in a single DbContext, or did have in separating its performance in order to obtain its process load is not heavy. thanks.

Upvotes: 4

Views: 391

Answers (1)

trevorc
trevorc

Reputation: 3031

Its not necessarily a performance issue as the DbContext uses IQueryable for your DbSets so each 'table' isnt materialized until you call ToList(), First(), etc. I have worked on projects (not my design) that have used over a 100 tables in a single context and the bottlenecks were never from a large DbContext. It just made the whole project unweildy and not something I would want to do again.

For larger projects whether its .net core or .net <=4.5 I would definitely go the bounded context route but structured from a DDD standpoint. Juli Lerman has written many blog posts about this and of course there is the blue book by Eric Evans which is the DDD bible.

Another DDD disciple is Jimmy Bogard where he expands on the DDD princples by delving into Value Objects, Aggregates, and Roots.

The short answer (too late) is that no, you don't have to worry about a 100 objects in your DbContext from a performance standpoint but by using DDD, Aggregates, Value Objects, Bounded Contexts, etc., you may find that the number of tables required will shrink and your project becomes much cleaner with greater separation of concerns.

Upvotes: 2

Related Questions