In the recent blog post, How We Talk about EF and its Future Versions, the EF team announced that going forward, the stuff of EF that’s in .NET, will be referred to as the EF Core Libraries. For example, .NET 4 contains EF 4…that’s now core libraries. When .NET 4.5 is released, whatever is contained within System.Data.Entity.dll will be EF 4.5 Core Libraries.

As you may know by now, Code First and DbContext were released out of band of the .NET release schedule and is contained in the EntityFramework.dll assembly which is distributed via Nuget. Code First and DbContext rely on the core libraries to do their job. In the blog post, the team says “we are going to focus on the EntityFramework NuGet package as the primary deliverable that we refer to as “The Entity Framework” or “EF”.

This allows the team to be more flexible in releasing new features that leverage all of the work that’s gone into Entity Framework – features such as Code First and the DbContext API.

(For anyone writing or blogging etc about EF, please keep these differences in mind and be attentive to how you express EF.)

However, there’s something more important that I took away from the team’s blog post based on the fact that what’s in the NuGet package (DbContext and Code First) is what the team now refers to as “Entity Framework”.

What this means to me is that DbContext and Code First are the first features you should consider when approaching Entity Framework.

This makes a lot of sense to me. DbContext is much simpler to use than ObjectContext and will serve the most common development needs. if you need more, you can drop down into the ObjectContext. Remember that DbContext sits on top of the ObjectContext. The ObjectContext is always there in the background doing it’s work. So if you need to do something very granular, DbContext provides a hook to its underlying ObjectContext. Check out this blog post for how to do that: Accessing ObjectContext Features from EF 4.1 DbContext. Or, if you are already committed to working directly with the ObjectContext, you can still do that.

What about database first and model first? The designer is still inside of Visual Studio (and getting improvements) and there are 3rd party designers as well. If Code First doesn’t do the trick for you, you really want a visual model — or you’re already committed to EDMX — no worries. The feature  is still there and you will not be a pariah for using the designer. Use the best tool for the job … for *your* job!  (Here’s an article I wrote about choosing between db/model & code first)

The core EF Libraries know how to use the XML based metadata that come from the EDMX. At runtime, EF uses an in-memory representation of your model. If your model is expressed in XML (from the designer), the ObjectContext knows how to read the XML to create what it needs at runtime. (Even if you’re using DbContext + EDMX, this works…because DbContext has an ObjectContext behind it). If your model is expressed in classes plus Code First configurations, the context knows how to use those pieces to build the in-memory metadata at runtime. After that, EF doesn’t care where the model came from.

So the primary focus of Entity Framework going forward will be building models with your classes plus Code First and managing your entities with the DbContext. When the team talks about Entity Framework, (according to their blog post) that’s most likely what they’ll be referring to.

There’s ANOTHER take away here. Code First leverages the POCO support that was built into the core in .NET 4. (see what I just did there? ) EntityObject is now the ugly step-child of Entity Framework. After working mostly with POCOs in EF for over a year now, I feel the same way about EntityObject. No love lost there!

When the team makes changes to how the core EF libraries (those which are part of .NET), again …popular examples are upcoming enum support and spatial data support … they’ll be clear that this is part of the core. Changes to the core benefit all of the ways to use EF …whether you build your model with a designer or with code and whether you use the ObjectContext or DbContext.

I’ve just finished up a book with Rowan Miller that is something of an extension to my book, Programming Entity Framework Second Edition (which is focused on Entity Framework 4). The new book is about 150 pages and is called “Programming Entity Framework Code First: Creating and Configuring Data Models from your Classes”. Very specifically about the modeling/mapping and DB initialization. We are now embarking on another short book that will be Programming Entity Framework DbContext. This second one will be focused on the DbContext APIs, validation and how to use them in various application patterns.