This is what I’ve realized about using the latest iteration of EF4’s Code First in the EF Feature Pack CTP. (I will keep clarifying that code first and the new EF bits in the CTP are a preview, not for production and subject to change…)
When using code first where you simply create your domain classes and define a DbContext to manage them, Entity Framework quietly slips into the background and does all of it’s work – transforming LINQ queries into store queries, executing them on your behalf, reshaping the query results into your classes, change tracking and then handling persistence to the database.
Between code first’s behind-the-scenes automatic model creation and some of the small but impactful additions to the core API (e.g., DbSet and DbContext), when creating simple applications, you will no longer have to be focused on how to design an Entity Data Model or write Entity Framework code, because most of that will be taken care of you by these new features. Calling context.Customers.Add(myCustomer) doesn’t feel too much different than working with any other collection in .NET. Compare that to context.Customer.AddObject(myCustomer) which your .NET brain fights (just ask Chris Sells :)). Or context.Customers.Remove(myCustomer) which correctly implies that you are removing something from a collection vs. context.Customers.DeleteObject(myCustomer) which is unnatural, but worse, incorrectly suggests that you might be actually deleting this from the database.
While this does feel like an epiphany (oh, it’s just programming) and people like Scott Hanselman are calling code first “the magic EF unicorn”, keep in mind that as you start architecting more complex applications, you’ll still have a lot to understand about the behavior of EF and how to work with it. So, no, I’m not calling “stop the presses” on my book.
Code First will not be for everyone. Many people want and need to build their model by reverse engineering an existing database. Many people like using a modeling tool. That’s why EF has these options and that’s what drove the alignment of the names:
- Database First
- Model First
- Code First
Use what works for you…
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
Presumably we can use the new DbSet and DbContext and keep everything nice and POCO without being strictly "Code First". I could have an existing database and hand write the code so that it matches it. But do you know whether we will be able to reverse engineer the database into code? So database first, but no diagram, and code that we can then edit to add business logic (and therefore design patterns like Entity, Aggregate and Repository).
Thanks,
Jason
Yes the DbSet & DbContext will be part of the core EF API available regardless of which-first you use.
Not sure if team will aim for that other avenue – db to code. Are you familiar with the fact that you can do code gen (your own template even) and then use partial classes to add business logic?
Hi Julie,
Does RIA Services support EF Feature CTP4 Code First? I would like to use these new features in Silverlight (4), instead of ServiceContext : LinqToEntitiesDomainService<EntityModel>.
Thanks,
Andries
@Andries
As far as I can tell you can’t do it with the tools. But I only did a few experiments. Remember code first is just a preview so I would not expect any of the other VS tools to understand it at this point. Might want to check with the EF team…perhaps ask the question in their blog post on code first.
Hi Julie, thanks for the reply. Yes I am aware of partial classes.
For now, I see being able to reverse engineer from a database as being the most useful… however if MS can do some magic to automatically add columns etc. (without recreating the database) then I can see a move towards code first for larger databases as well. If it were robust and complete enough we may even be able to do it in production and not have to apply database update scripts… that would be really cool.
@Jason
Take a look at the edm designer powerpack. It has a db schema "upgrade" feature. I haven’t tried it yet. visualstudiogallery.msdn.microsoft.com/…/df3541c3-d833-4
Great blog post, looking forward to your DevProConnections article.
I am on a Silverlight project that uses a WCF Data Service, there is a lot of legacy code (derived and collection classes that make calls to the DB) that we want to reuse.
The one "grey area" for us is to figure out the best way to utilize the legacy classes with EF4. When I create a WCF Data Service it references an “Entity Container” which is normally found in the CSDL of the EDMX file: <EntityContainer Name="FieldManagementEntities”>
In many POCO examples there will be two projects in VS2010 that only use class files. If I try that approach and inherit from the objectContext or dbContext in a class file and then run (View in Browser) the WCF DataService I get the following error: The server encountered an error processing the request. See server logs for more details
My guess is when creating an EF DataModel additional code is written via the designer so a Data Service will work automagically.
I really need to see a code example that includes a WCF service with POCO.
Thanks in advance for any help or direction.
Hi,
Interesting post where a sense a hint of defensiveness? Don’t worry – I’m sure your book will still sell lots of copies 😛
@Nick – not sure where you got the "defensiveness" but there’s none coming from me…
Sadly, it is still woefully behind Fluent NHibernate’s automatic mappings capabilities. I was hoping to see more improvements in this area as more previews are released, but they don’t seem to be taking it there, which just means we have to code more.
Maybe they’d benefit from a list of what you’d like to see. It’s still just a preview that is evolving.
@Jason Which capabilities do you feel are missing? Bear in mind automatic mapping is the default unlike FNH so if you’re looking at API’s you may be mislead into thinking it’s missing.
[)amien
I wonder how this plays along with depdency injection and n-tier applications. When you say "Entity Framework quietly slips into the background" will the dbcontext invade my top tiers? Will I still be able to cleanly separate the layers?
Do I sense some lack of enthusiasm from you on Code First – with this ‘just use partials’ comment above ?
Don’t get too excited at the best news we’ve heard from the EF team in quite some time (for me EFv4 was a bust – all this ‘POCO’ talk and it was nothing more than more generated code without attributes – lol)
@Steve
Huh?