Entity Framework 4 – Code First

Entity Framework 4 itself is interesting but what really got me hooked was the CTP 4 preview, and what Microsoft call “Code First”. Code First allows us to describe our model using regular POCO classes, instead of designing our model using either the EF editor or creating in directly in the database.

A very simple example of this would be to create a two classes to store blog entries and comments.

    public class BlogEntry
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string Body { get; set; }
        public virtual ICollection Comments { get; set; }
    }

    public class Comment
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Text { get; set; }
    }

As you can see, this is regular C# classes, no decorators or inheritance involved. Now we need a class that will access the database:

    public class Db : DbContext
    {
        public DbSet BlogEntries { get; set; }
        public DbSet Comments { get; set; }
    }

To try out storing and retreiving some values, i created a simple console application:

using System;
using System.Collections.ObjectModel;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            var db = new Db();

            // Create a new video
            var blogEntry = new BlogEntry() { Title = "Coding some EF in VS2010", Body = "Pretty sweet!" };

            blogEntry.Comments = new Collection();
            blogEntry.Comments.Add(
                new Comment()
                    {
                        Name = "Han Solo", 
                        Text = "Great article, will show it to Chewbacca"
                    });
            blogEntry.Comments.Add(
                new Comment()
                    {
                        Name = "Darth Wader", 
                        Text = "Good work my son, you are just learning to know the power of the dark side"
                    });
            
            
            db.BlogEntries.Add(blogEntry);
            db.SaveChanges();

            // Loop videos and 
            foreach (var v in db.BlogEntries)
            {
                Console.WriteLine("BlogEntry Id: " + v.Id + ", Title: " + v.Title);

                Console.WriteLine("Comments:");
                foreach (var tag in v.Comments)
                {
                    Console.WriteLine("  Comment Id: " + tag.Id + ", Name: " + tag.Name);
                }
                
            }
        }
    }
}

Executing the program prints (not very surprising):

PS > .\ConsoleApplication1.exe
BlogEntry Id: 1, Title: Coding some EF in VS2010
Comments:
Comment Id: 1, Name: Han Solo
Comment Id: 2, Name: Darth Wader

Now to the interesting part, what really happened?

If we start SQL Management Studio and connects to my local SQL server express instance we can see that Entity Framework has automatically mapped the POCO objects to tables and setup the corresponding relations.

And we can see that the data got stored:

So far so good, now we come to the part where EF code first isn’t really mature enough yet. Say we want to make a small change to our Comment class, add a new property for example. The application will compile without compiling but the next time we run the application it will throw the following exception:

Unhandled Exception: System.InvalidOperationException: The model backing the ‘Db’ context has changed since the database
was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer
instance. For example, the RecreateDatabaseIfModelChanges strategy will automatically delete and recreate the database,
and optionally seed it with new data.
at System.Data.Entity.Infrastructure.CreateDatabaseOnlyIfNotExists`1.InitializeDatabase(TContext context)
at System.Data.Entity.Infrastructure.Database.Initialize()
at System.Data.Entity.Internal.InternalContext.Initialize()
at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
at System.Data.Entity.Internal.Linq.EfInternalQuery`1.Initialize()
at System.Data.Entity.Internal.Linq.EfInternalQuery`1.GetEnumerator()
at System.Data.Entity.Infrastructure.DbQuery`1.System.Collections.Generic.IEnumerable.GetEnumerator()
at ConsoleApplication1.Program.Main(String[] args) in C:\Dev\ConsoleApplication1\ConsoleApplication1\Program.cs:line
33

Which means that we pretty much has to delete the database and recreate it after every change we make – definitely not how i would prefer to work.

Conclusion
EF code first looks like a step in the right direction, but in order to make it usefull EF must provide automatic database migrations without loosing data, both for development use and for production use.