I received this pair of questions about EF in email and thought I would share the questions and my reply.
Q:
I’ve read some articles about Code First, I’ve tried to do some samples and I’m going to read you last book.
I’m surprised about 2 issues. The first is that it’s possible to write native SQL code (with context.Database.ExecuteSqlCommand and context.Database.SqlQuery methods) and the second is that I’ve not been able to use EntitySQL or Query Builder Methods.
Now, the idea of EF was create a model, operate with objects and use a common language (EntitSql) to interact with "some" databases. But now? We are coming back? Yes, we can use Linq2Entities and SaveChanges but I don’t understand the philosophy of these opened doors upon the database.
I’m wrong?
What’s your idea?
My A:
Dbcontext doesn’t replace ObjectContext. It just makes it easier for devs to access the most common things.
You can still use ObjectContext. You can even use DbContext and access ObjectContext functions when you need to.
Entity SQL was created before the data team knew about LINQ. You can express most queries with LINQ and it works with any EF-compliant database provider, just as ESQL does.
The direct database access command features are a "backdoor" that devs asked for. It should be used only on rare occasions when you need to access something in the database that is not part of the model.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
I really love that SqlQuery feature on the DbContext.Database. If we’d had that in EF 3.5 (or is that EF 1?) then it would have made stored procedure handling sooooo much easier.
As someone whose "career arc" has gone from developer, to dba, to db architect – I can tell you right now that these "backdoor" features are critical for EF gaining acceptance in large orgs with LOTS of existing databases.
I love code first (really I do!). But I was disappointed that database-first didn’t get additional MS attention. I see no reason why the MS ADO.NET folks couldn’t do a better job in (for example) generating POCOs with annotations based on an existing database. As you know, the TT templates pretty much slams the door on "database first" when it sets Code Generation strategy to None.
Why does there need to be a "backdoor"? That is how things get handled incorrectly or hacked. Why not build in greater support for database access through stored procedures instead of pushing over use (IMHO) of LINQ (it has its benefits in some cases). Database first should get more thought…
At Mike in NH, you should read this blog post. Database first code generation is awesome. thedatafarm.com/…/mvc3-1-scaffold