Entity Framework 4.1 Code First

Introduction

In this post I will focus on Entity Framework 4.1 Code First technology which allows developers to first code their domain and from that code generate database without writing any line of SQL code. Such approach is encourage by Domain Driven Development (DDD) methodologies since they states that creating a database first results in more data centric model than it should be obtained.

Problem definition

Entity Framework 4.0 has many advantages and really makes creating data access layer very easy. But it also has some disadvantages. One of the biggest drawbacks is fact that entity class created by EF are not persistence ignorant – they contains many informations about way of storing them in database. Such approach breaks one of the most important principle of object oriented development – the separation of layers. As a solution to this problem Microsoft presented POCO objects in EF – entity classes which are persistence ignorant ( they can be coded or created automatically by a template based on T4). But many developers and specialist were still unhappy – EF 4.0 required to first create database and the model and at the end create the POCO classes and map them to the model. Such solution were discourage  by DDD methodologies which states that the first thing should be coding classes not database.

Solution

The Entity Framework 4.1 release is built on top of the 4.0 release of the EF. The Entity Framework 4.1 introduces a new DbContext API, and enables Code First development. Code First enables you to define your model by using C# or Visual Basic .NET classes, configure the model and generate a database schema from it, or map your model to an existing database. Now, I will describe several basic steps for creation very basic Code First model and generating database on bases of it. The first step is creating a new class library project and adding all references needed by EF 4.1 ( this can be done easily by NuGet Package Menager: Install-Package ”EntityFramework” ). Next step is coding our model. Below, I present three classes representing simplified version of Library model – class Book related one-to-many with class Genre and releted many-to-many with class Author.

public class Genre
{
   public int ID { get; set; }
   public string Name { get; set; }
}

public class Author
{
   public int ID { get; set; }
   public String Name { get; set; }
   public IList<Book> Books { get; set; }
}

public class Book
{
   public int ID { get; set; }
   public string Title { get; set; }
   public Genre Genre { get; set; }
   public IList<Author>  Authors { get; set; }
}

Next step is creating a context class which represents our database and has to inherit from DbContextclass.

public class LibrayContext : DbContext
{
   public IDbSet<Book> Books { get; set; }
   public IDbSet<Author> Authors { get; set; }
   public IDbSet<Genre> Genres { get; set; }

   protected override void OnModelCreating(DbModelBuilder modelBuilder)
   {
      modelBuilder.Entity<Book>()
         .HasMany<Author>(a => a.Authors)
         .WithMany(b => b.Books)
         .Map(m =>
            {
               m.ToTable("BooksAuthors");
               m.MapLeftKey("BookID");
               m.MapRightKey("AuthorID");
            }
         );
  }
}

As we can see the sets of entities are represented by generic IDbSet interfaces. Another important fact is implementing many-to-many relationship what is done by function OnModelCreating. In this function we define points where exist many-to-many relationship and than we map this relationship to the another table.

And this is all!  Now we can create small test program by creating new project ( i.e. Console Application) and manipulate on some data as in normal EF ( using LINQ to Entities or EntitySQL). After first invoking of any statement over database  it will be created on the server. Below I present the database schema which I obtained from above Code First model.

Conclusion

In this post I presented Entity Framework 4.1 Code First API. Using it allows developers to create well defined domain models based on DDD which are persistence ignorant and don’t break layer separation rule. In next posts I will describe how to extend POCO classes by some methods ( due to layer separation and definition of POCO it shouldn’t be done by just adding methods to above definitions) and provide validation for them.