I initially had a DbContext with all DbSets of my entities. However, I needed to create a DbContext<T> that has a generic DbSet for methods that are properly generic. It turns out that the two DbContext point to the same connectionstring. Can the existence of both in a project be considered bad practice? If yes, what would be the most feasible way to perform generic operations with a non-generic database context ?
Having two dbContext for the same connection string is considered bad practice?
2
asked by anonymous 08.07.2014 / 23:10
2 answers
4
Having a DbContext can be a bad practice if the entities it contains are not related to each other.
Following the DDD - Domain-driven design approach, when we are facing many entities, they must be grouped according to the context in which they relate.
For example, if your application has to handle the stock and personnel area of a company, two DbContext should be defined, one for the Stocks entities for Personal entities.
See here for DDD.
Regarding your specific question, I do not see the need to have two DbContext .
Note: Having more than one DbContext for the same connection string has no problem at all.
09.07.2014 / 11:34
3
Yes.
A context not only controls the loaded objects, but their states and all changes to the records made within it.
By loading these objects into separate contexts, changes made to the same record for both contexts may be lost, causing information inconsistency.
Try to use only your DbContext<T> for all Controllers . I did not exactly understand the motivation to have a generic and a non-generic context, but there is no need for it.
09.07.2014 / 08:24