Is Dbcontext the Same as Datacontext

Is DbContext the same as DataContext?

DbContext is a new class that was added in the recent separate download by EF team. It is currently not part of the core EF 4.0. However DbContext moving forward would be the preferred way to interact with EF.

So how is it different from ObjectContext? Well semantically they are exactly same but they reduced lot of extra noise that ObjectContext had. Like exposing a set required more work, for instance:

public ObjectSet<Customer> Customers
{
    get { return db.CreateObjectSet<Customer>(); }
}

With DbContext you can do:

public DbSet<Customer> Customers { get; set; }

Basically on the ObjectContext, when you do dot (.), everything is just right there which makes the list pretty huge. What the EF team actually wanted to expose on DbContext are entities which are only specific to your domain and rest of ability of the framework is tucked in under different properties. It just makes the programming experience easier.

This means if you are using ObjectContext right now, with a little bit of code, you can easily move to DbContext.

DataContext vs implementation of DbContext?

You could have a constructor taking the connection string as parameter:

public ProjectDataSource(string connectionString) : base(connectionString)
{
}

and then:

public void Initialize ()
{
    _dataSource = new ProjectDataSource(connectionString);
    _datasource.Database.Delete();
    _datasource.Database.Create();
}

Is Unit of Work pattern about sharing the same DataContext?

Yes, you share the same DataContext. Here's a tutorial that will help you: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

ObjectContext' vs 'DbContext' in Entity Framework

DbContext is just a wrapper around ObjectContext.

DbContext is just a set of APIs that are easier to use than the APIs exposed by ObjectContext.

Anyway, here you'll find a very simple Visual Studio template that uses the Repository Pattern and the Entity Framework.

Are DataContext a kind of new version of DataSource?

(It sounds you mean the FrameworkElement.DataContext property that appears in WPF. If not, oops.)

It's somewhat similar to DataSource, but is much more flexible. In WPF, a DataContext can be literally any object that has properties. To bind to a property, you just specify its name and WPF takes care of the rest for you by fishing the specified property out of the DataContext with some reflection magic. (Fields are not supported.)

For example, if you're binding a view (say, a UserControl or Window) to an Employee object:

class Employee {
    public string FirstName { get; set; }
    public string LastName { get; set; }
    // more stuff. . .
}

then you just set its DataContext to that object. Then the XAML for displaying information from that Employee object could be as simple as:

<Label Content="{Binding FirstName}"/>
<Label Content="{Binding LastName}"/>

Optionally, the DataContext can provide additional functionality that allows for richer binding. For example:

• If it implements INotifyPropertyChanged or has dependency properties, changes to the DataContext will be automatically reflected in the UI.

• Properties that have setters support two-way binding.

• If it implements INotifyDataErrorInfo then you can do form validation.

• If it's an ADO.NET object, you get all the usual ADO.NET binding magic.

Is there a DataContext in LINQ-to-Entities (NOT Linq-to-SQL)?

LINQ to Entities uses ObjectContext, not DataContext.

Here is a short description of EF:

LINQ to Entities, the ObjectContext Class, and the Entity Data Model

LINQ to Entities queries use the Object Services infrastructure. The
ObjectContext class is the primary class for interacting with an EDM as
CLR objects. The developer constructs an ObjectQuery instance through the
ObjectContext. The generic ObjectQuery class represents a query that returns
an instance or collection of typed entities. Entity objects returned by
ObjectQuery are tracked by the Object Context and can be updated by using
the SaveChanges method.

It doesn't even work the same way as the DataContext in LINQ to SQL.
While it is true that they both manage the connection and track changes, yet they differ in how they model the data structures and relationships.

I would give the poster of that wrong answer some slack, though, because LINQ to SQL does make reference to "entities", and someone not familiar with EF could very well still be thinking they know what you are talking about.

For example:

LINQ to SQL and the DataContext Class

The DataContext is the source of all entities mapped over a database
connection. It tracks changes that you made to all retrieved entities and
maintains an "identity cache" that guarantees that entities retrieved
more than one time are represented by using the same object instance.

It can be confusing.

More than one DbContext was found

It looks like there are several classes that have been inherited from DbContext class (may have come from some NuGet package). So add migration with

Add-Migration MyMigration -context DataContextName

---

Related Topics