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.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
11 thoughts on “Code First and DbContext are now “The Entity Framework””
Pingback …. @ http://gtaskos.wordpress.com/
Thanks for the nice article.
It’d be nice that now some additional tooling could be added to EF Code First as well. There’s really no reason that ‘Code First’ has to be really code first. Model -> Db -> Model synching certainly would be on the top of the list of features for any ORM solution.
Glad to see focus is going to EF CF though – certainly is a lot nicer to work with than EntityObject was.
HELP! We have concerns that EF-generated SQL may not be fast/scalable enough for large batches compared to SPs, and we really like the failback flexibility of being able to use Code First POCOs with SPs (only when needed). But DbContext doesn’t support SPs – any thoughts around this?
You can execute stored procs directly from DbContext.Database.ExecuteqlCommand.
What’s not supported is mapping sprocs to entities.
Does that make a difference?
Can we use stored procedure with EF CF?
If I work with an existing DB, can I use the EF Code first ? If yes, in this case, the objects are loaded in a designer?
I’m a bit confused cause I’m new to EF and I don’t know with which version will I procede to lear EF.
You can execute stored procs with DbContext but you cannot *map* sprocs to entities with Code First if you want SaveChanges to automatically use your insert/update/delete sprocs instead of generating its own SQL. I have no idea when this will change.
Want to be sure you grok the difference between those two features (just executing and mapping to entities) so you know which one you’re looking for and make the correct decision.
grok is actually a word. I thought it was tech jargon. I had to look it up.
Le code source ne marche pas
I've found that DbContext, DbSet, DbQuery do not allow you to specify the MergeOption. You can with ObjectContext, ObjectSet and ObjectQuery.
I really need to have it set to OverwriteChanges or PreserveChanges.
When you have a dbcontext instance, you can tunnel down to the underlying objectcontext if you need to set those mergeoptions explicitly. (example here: http://thedatafarm.wpengine.com/blog/data-access/accessing-objectcontext-features-from-ef-4-1-dbcontext/)
The NoTracking option, btw, is available for queries i the DbContext API. See "AsNoTracking".