I don't know if there is a better way to use the DbContext
because it is not recommended to set is as static when working with WCF. So we are creating it each time we want to access the database.
Knowing all the advantages of using Entity Framework, some become useless since we are recreating the DbContext
each time; and more may cause overhead since the process of creating big entity models is to be considered.
What is your opinion?
A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.
Don't dispose DbContext objects. Although the DbContext implements IDisposable , you shouldn't manually dispose it, nor should you wrap it in a using statement. DbContext manages its own lifetime; when your data access request is completed, DbContext will automatically close the database connection for you.
In code first, you can have multiple DBContext and just one database. You just have to specify the connection string in the constructor. Yes you can, but how can you query from different entities from different db contexts?
The DbContext class is an integral part of Entity Framework. An instance of DbContext represents a session with the database which can be used to query and save instances of your entities to a database. DbContext is a combination of the Unit Of Work and Repository patterns.
You're correct that a single static instance of DbContext
is usually not recommended:
The more you use an ObjectContext, generally the bigger it gets. This is because it holds a reference to all the Entities it has ever known about, essentially whatever you have queried, added or attached. So you should reconsider sharing the same ObjectContext indefinitely.
These comments apply directly to the DbContext
, because it wraps wraps ObjectContext
to expose "simplified and more intuitive APIs." [see documentation]
The overhead of creating the context is relatively low:
The reality is this cost is actually pretty low, because mostly it simply involves copying, by reference, metadata from a global cache into the new ObjectContext. Generally I don’t think this cost is worth worrying about ...
The common way to work with a short-lived context is to wrap it in a using block:
using(DbContext context = new SomeDbContext()) { // Do work with context }
To ease with testing, you may want to have your DbContext
implement some IDbContext
interface, and create a factory class ContextFactory<T> where T : IDbContext
to instantiate contexts.
This allows you to easily swap any IDbContext
into your code (ie. an in-memory context for object mocking.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With