I’ve been asked repeatedly about the viability of my book, Programming Entity Framework, and the other EF4 books out there now that EF 4.1 has been released.
The EF4 books are still totally viable and important if you truly want to learn Entity Framework for the purpose of writing enterprise applications.
Entity Framework 4.1 simply adds two new features to Entity Framework. The first is an additional way to create a model, called “Code First”, the second is a stripped down version of the ObjectContext. They are *awesome* additions for those who like to program this way. And you can always hook back to the ObjectContext if/when you want to get the granular control you will likely need if you’re writing an enterprise app. I love code first and I love the DbContext. But I also love Database First for many scenarios, Model First for many scenarios and the extreme power that the ObjectContext provides me when I want it. And when I’m writing real apps, not just demos, I definitely want the ObjectContext available to me!
The core APIs don’t change.
The need to understand the ins and outs of the conceptual model and mappings doesn’t change.
The need to understand how to use EF in an application shifts at the surface, but if you need to do more than simple drag & drop applications, you’ll need to understand how to work with the underlying API.
The need to understand how EF works and how you can manipulate to improve performance, to do threading, to control transactions does not change.
The need to understand how changes are tracked and how relationships are managed and how to affect those features so that you can make application back ends work the way you want them to does not change.
Currently my recommendation is that if you think you want to use Code First and the DbContext, take a look at what’s in there (great blog posts by EF team at blogs.msdn.com/adonet, a series of 11 short videos (with accompanying articles and download samples) that I created for MSDN at msdn.com/data/ef, a new EF 4.1 course (and more coming) on Pluralsight and many articles & blog posts written by very knowledgeable community members) to learn how to use code first and DbContext when working with EF.
But if you are writing applications with Entity Framework, you’ll still want to learn how to program with it. And for that, you have three great books that you can learn from – all take a different approach and they are quite complementary to each other. Yes, mine is one of them and of course I recommend it. I spent a year on the first edition and another year on the second edition. I worked very hard to learn EF inside and out to help you learn it, too. I also recommend Entity Framework 4.0 Recipes and Entity Framework 4 in Action. Again, these books take a very different approach than mine and in my opinion, the three books complement each other nicely.
In case you think this might be a desperate attempt to sell more books, it is hardly that. Tech book authors get a *very* small royalty per book sold. Tech book writing is not typically a financially rewarding endeavor. Instead, the desperate attempt I’m making is to offer a better explanation for the many people who keep asking me when I will be updating my book to EF 4.1 – a better response than I can provide in the 140 characters on twitter.
The out of band release of EF 4.1 may be followed by others so right now EF is a moving target. Updating Programming Entity Framework to incorporate the new features just doesn’t make sense. I think using the core books to learn EF and then supplementing with the EF 4.1 content that can be produced and shared more quickly (online articles & videos from trusted resources) is your best bet.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
7 thoughts on “EF4 books and EF 4.1”
Another great post! I love your EF videos on Pluralsight! And I find your approach very helpful, because simplicity is understanding of the whole
Why do you call DbContext a stripped down version of ObjectContext? I thought it is just reworked ObjectContext with better syntax and some pretty features (Reference vs. Include). Are there any features DbContext doesn’t have in comparison to ObjectContext?
@Alexander: "Stripped down" is not quite fair. It’s actually a combination of that and what you explain and I should have expressed that better. ObjectContext has a lot of methods/properties that are not used as commonly. DbContext doesn’t bother exposing them, ergo "stripped down". But also, DbContext & DbSet simplify access to some of the features that we have to work hard to get at with ObjectContext …e.g. providing the "Local" method to get at entities that are being tracked by the context and not doing another db execution, "Find" to do a quick primary key search, etc.
Also there is one thing that you cannot do with DbContext which is CompiledQuery.
>>Also there is one thing that you cannot do with DbContext which is CompiledQuery.
But we can always access ObjectContext from DbContext, right 😉
ha – great minds think alike! 🙂 Yes, but you cannot trick compiled query by doing that. I spent hours trying and also asked the team, who replied that they had also spent a lot of time trying a work around with no success.
Or fools seldom differ in this case 😉 Thank you for discussion!
Can anyone help me figure out how to generate a setup for my project that is using entity framework.
Am having issues with the connection string at production server.