CODEWITHSUNDEEP
c#asp.netentity-framework
Elad Benda
Elad Benda

Reputation: 36656

What's the difference between DbContext and ObjectContext

From MSDN:

Represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.

I though DbContext only handle the connection to the DB and the number of threads working against the DB.

Now I understand it contains the tracking mechanism? I thought this was in the ObjectContext.

So what is (in plain English) the difference between them?

Upvotes: 20

Views: 20680

Answers (3)

yogesh lodha
yogesh lodha

Reputation: 301

Object Context:

1.It support compiled query 2.It support self tracking of entities 3.It available for entity frame work 4.0 and below version 4.It is not thread safe. 5.It is best for DB first and model first approach.

Database Context:

1.It does not support compiled query 2.It support not self tracking of entities 3.It available for entity frame work 4.1 and above version 4.It is thread safe for static and share member(public). 5.It is best for DB first and model first approach and code first approach.

Upvotes: 1

Corey Adler
Corey Adler

Reputation: 16137

DbContext is a lightweight version of the ObjectContext class, which is laid almost right on top of ObjectContext (there is even a way to get to the ObjectContext from just the DbContext). It's also a lot easier to use, IMO, and makes CRUD operations a sinch.

For better information, who better to look to than Julie Lerman for more info on the differences, as was brought into EF 4.1.

Upvotes: 21

sushil pandey
sushil pandey

Reputation: 762

the DbContext is a smaller API exposing the most commonly used features of the ObjectContext. In some cases, those features are mirrored in the DbContext API. In other cases, the Entity Framework team has simplified more complex coding by providing us with methods like Find or properties like DbSet.Local. But there’s a big API lurking underneath that you may still need access to. For example, you might want to work directly with the MetadataWorkspace to write generic code against classes because that API can read the model more efficiently than reflection. Additionally, the MetadataWorkspace is able to provide more information about the metadata than you can discover with reflection, for example, for Key properties. Or you might want to take advantage of a database-specific function that is exposed through Entity SQL, which you can’t access from LINQ to Entities. Or you may already have an application written using the ObjectContext and you want to leverage the DbContext in future updates without replacing all of the ObjectContext code.(Reference from Programming DbContext)

Upvotes: 6

Related Questions