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…

There have been a lot of improvements to code first since CTP3 and in fact, the team has been experimenting with changes to the core Entity Framework APIs that not only support even simpler programming with code first but that we’ll benefit from in an upcoming release of .NET. (No, I don’t know if there will be a service pack and when…)

I have a code first sample in my book, Programming Entity Framework 2nd Edition, that is coming out in August and was lucky with the timing of the CTP4 release because I was able to sneak in an overhaul of that section before the book heads to the printer.

In revising my code sample for that section I was very happy with so many of the API & Code First improvements.

**But first a clarification is important. The version of Entity Framework that is in .NET 4/VS2010 is the current shipping, supported version that you can use in production. What’s in the CTP is simply an early look at what’s coming as it evolves giving us a chance to play with it. This is not something you can deploy and it is also going to evolve with future CTP versions.**

So with that in mind, I went to town on the CTP3 sample.

The first thing that I benefited from was the new stripped down easy access versions of the ObjectContext and ObjectSet.

The new classes, DbContext and DbSet have the same essential functions but don’t expose you to the entire feature set of their big brother & sister. Not everyone needs all of those features. The are not derived from ObjectContext and ObjectSet however, but provide easy access to the full featured versions through a property e.g., DbContext.ObjectContext and DbSet.ObjectSet.

Along with this simplification are simplified terms.

Where ObjectSet has AddObject

context.Customers.AddObject(myCust) – note that Customers in this case is the ObjectSet)

DbSet simply uses Add

context.Customers.Add(MyCust) –>now I’m using Customers as a DbSet).

Another nice trick is how DbSets are created.

ObjectSet has an internal constructor and does not have a parameterless constructor,so you need a backing variable

ObjectSet<Customer> Customers;

and then you need to execute the CreateObjectSet method to create the ObjectSet:

context.CreateObjectSet<Customer>(“Customers”)

DbSet has a constructor so you can use an auto-implemented property

public DbSet<Customer> Customers { get; set; }

Code First gets way easier

It’s true. I cut out gobs of code and moved code to where it belongs.

Code first uses convention over configuration. It looks at your classes and does its best job of inferring a model and a database schema from it (if you are starting from scratch). Your classes don’t always provide enough metadata so you can provide more info to code first through additional configurations. Initially those configurations were programmatic only but now you can also use attributes in your classes (“data annotations”).

Here are two examples.

In my model I have a class called ConferenceTrack. It has an identity property called TrackId. Code first convention looks for “Id” or class name + “Id” as an identity but TrackId doesn’t fit this pattern so I have to tell EF that this is my identity key.

I can do that using code first’s ModelBuilder (formerly called ContextBuilder):

modelBuilder.Entity<ConferenceTrack>().HasKey(ct => ct.TrackId);

In CTP3, I had to execute from the same code that instantiates the context. Bad bad. Now there is an OnModelCreating method that I can use and put that configuration inside that method. The method lives in the context class. I don’t have to call it. The context is smart enough to run it for me.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
   modelBuilder.Entity<ConferenceTrack>().HasKey(ct => ct.TrackId);
}

Alternatively, I can configure this key right in my class as an attribute of the TrackId property.

    [Key]
    public int TrackId { get; set; }

Definitely simpler. I prefer to keep all of that EF related stuff in the context class so will most likely continue to use the fluent configuration rather than the data annotations.

Boy oh Boy did Relationships Get Easier

In my domain classes, I have a bunch of relationships defined through properties.

E.g.

ConferenceTrack has

public ICollection<Session> Sessions  { get; set; }   (a one-to-many relationship)

Session has

  public ConferenceTrack ConferenceTrack { get; set; }  (a many to one relationship)
  public ICollection<Speaker> Speakers { get; set; } (a many to many relationship)

In CTP3 I had a whole bunch of configurations defined (that were hard to construct and hard to read) so that the model would understand my intent with these relationships. CTP4 is now smart enough to grok my intent based on the domain class properties. And if there’s something that I want that doesn’t follow the convention, then I can add a configuration.

So I removed *all* of the configuration code that described the relationships.

That made me happy.

And EF/Code First figured it all out.

Based on my classes and the single configuration to define the TrackId as the key for conferences, it created this database to persist my data into

It worked out all of the relationships. Notice the Sessions_Speakers that it created for the many to many relationship.

Also, I have a class in my domain that is called Workshop and inherits from Session. By default Code First assumes Table Per Hierarchy. It created a discriminator column in the Sessions table which I need to use another configuration for to change its name to IsWorkshop.

There’s more to love about this CTP. You can get coding details from theEntity Framework Design and EF team blog’s newest posts and download the CTP here.

 As I’m learning more about domain driven development and as code first evolves, I’m getting more excited about this upcoming feature of Entity Framework

By now you know I’m prone to exaggeration so that “billions” thing is a stretch, but you get the point hopefully.

Lots of legacy databases have hundreds or even more tables in them.

People building Entity Data Models by reverse engineering a database often bring every table and view from the database into a single model.

Here’s an untouched model built from all of the tables and view of the AdventureWorks database – totalling about 95 entities.

This is already unmanageable and causes design time performance issues, and it’s not even 100 entities.

I get questions all of the time from developers asking what to do  with large models.

Here is a recent question I got via email":

“I have a database with 150+ tables. Would you break the model up into multiple edmx files?”

My response (with some enhancements for the sake of this blog post):

Yes I would. I have lots of clients working with multiple models. One approach is to think of a model per transaction. E.g., if you have a data entry screen that only needs 6 entities, build a model for that. (That may be exaggerated).

Take a look at:

http://www.ideablade.com/WardsCorner/WardsCorner_home.aspx  scroll down to his large model discussion & demo. Ward and I have come up with the same conclusion. Ward has written something like a dissertation as he goes through the pros & cons of various approaches to the problem.

Also, another approach to consider (with or without breaking up the model) is a different designer that doesn’t try to visualize all of the entities (which makes things so cumbersome with the EDMX designer). LLBLGen Pro is already a great ORM in its own right. But they’ve taken their knowledge and built a deisgner specifically for EF4 with the goal of dealing with larger models.

http://weblogs.asp.net/fbouma/archive/2010/04/28/llblgen-pro-v3-0-with-entity-framework-v4-0-12m-video.aspx

Finally, just as an FYI, I’m guest editing an upcoming issue of DevPro Connections magazine and specifically asked Patrik Lowendahl to write an article on this very topic.

In case you missed it (and are interested) there is an update (came in June) for Windows Azure dev tools. It’s version 1.2 and is supported in VS2008 & VS2010.

(http://www.microsoft.com/downloads/details.aspx?FamilyID=2274a0a8-5d37-4eac-b50a-e197dc340f6f&displaylang=en)

Most important to me is the .NET 4.0 support: now I can use EF4 in Azure services.

Windows Azure Tools for Microsoft Visual Studio 1.2 (June 2010)

Windows Azure Tools for Microsoft Visual Studio extend Visual Studio 2010 and Visual Studio 2008 to enable the creation, configuration, building, debugging, running, packaging and deployment of scalable web applications and services on Windows Azure.
New for version 1.2:

• Visual Studio 2010 RTM Support: Full support for Visual Studio 2010 RTM.
• .NET 4 support: Choose to build services targeting either the .NET 3.5 or .NET 4 framework.
• Cloud storage explorer: Displays a read-only view of Windows Azure tables and blob containers through Server Explorer.
• Integrated deployment: Deploy services directly from Visual Studio by selecting ‘Publish’ from Solution Explorer.
• Service monitoring: Keep track of the state of your services through the ‘compute’ node in Server Explorer.
• IntelliTrace support for services running in the cloud: Adds support for debugging services in the cloud by using the Visual Studio 2010 IntelliTrace feature. This is enabled by using the deployment feature, and logs are retrieved through Server Explorer.

As a test, I just built a new WCF Service Role (verifying that it is, indeed, a .NET 4 project), added a EDM to it (it’s not architecture, it’s a proof of concept) and pointed my EDM to one of my SQL Azure databases. I created a simple service operation to return data via the EDM. Then I created a client app which retrieved the data through that service operation. Easy-peasie.