Good practice to use a different DbContext class for every page? [closed]

Question

I am in the process of optimizing and refactoring a large ERP-type ASP.NET application to achieve a faster development experience. We currently have a large model (600+ tables/entities) that is created when the application starts which take around 15 seconds. (At this point, we are using NHibernate with code-first mappings)

I am trying to achieve the fastest rendering of the page after compilation is done.

I was wondering if it would be a good practice to have one DbContext per page which would include only the required entities/mappings to use this page. Every page is viewed as a distinct element and can be carried around on its own.

EDIT: I am not talking about reusing an instance of a DbContext, but a different object with different DbSets. A different instance would be created for every request.

Answer 1

I was wondering if it would be a good practice to have one DbContext per page which would include only the required entities/mappings to use this page.

I don't think this is a good idea to have one dedicated DbContext type per page.

• Each DbContext's type model will hold a memory footprint during the whole app domain lifetime. I would say the footprint will be something like 5MB for around 20 entity types.
• You will have a hard time defining the boundaries of each of your DbContext types ( ignoring navigation properties of your entities on a case by case basis will force you to define a lot of dedicated mapping configurations ). Not that this a bad idea, but I guess the Linq support would be almost useless, and I think a micro-orm would be better suited for this approach.

You may also go for bounded contexts : Separate your domain model into sets of entities corresponding to the same concern (let's say at most 50 entities per concern) and use a dedicated DbContext type per concern (without navigation properties across entities of different DbContexts). Note that you may define very simple cross-concern (mostly readonly) mappings to use cross concern concepts across your whole app (for example, a UserSummary entity exposing the main properties of the User entity)

As to speed-up startup, I guess this can help 3 STEPS FOR FAST ENTITYFRAMEWORK 6.1 CODE-FIRST STARTUP PERFORMANCE

Answer 2

It's a good practice to use DbContext per each request.

If you render partial pages on your View it's better if you still use same context.

Your context disposed automatically at the end of your request in general (Of cource there are some exceptions if you create your context on application start for example but you shouldn't do this anyway) but it's better dispose it manually at the end of request.

But if you talking about best perfomance i was on conference where StackOverflow team talking about how SO working (it's written on MVC as well).

They say that they don't use EF or any other ORM at all becouse it creates lots of intermediate objects and GarbageCollector can't dispose it fast enought. So they writing all on good old plain ADO.NET