;

Persistence Ignorant POCOS part 5 – EntityFramework CodeFirst

Posted : Sunday, 03 April 2011 21:32:50

This is the final post in a series comparing the developer experience of wiring up an existing application to use some of the more popular ORM tools out there. In this post I will adapt the LightsCameraAuction application to use EntityFramework version 4.1 – specifically CodeFirst. CodeFirst has been developed following community feedback generated in response to the earlier iterations of EntityFramework – notably the rather complex process required to wire up EntityFramework to an existing database (see post 2 in this series) and in my opinion the far more restrictive requirement to derive all Entities from a single base class – e.g. the lack of POCO support. CodeFirst allows POCO CLR classes to be persisted, change tracked and life-cycle managed by the EntityFramework. This is achieved via the use of new lightweight version of the ObjectContext class called DbContext. As well as POCO support, CodeFirst also supports a fluent mapping interface thereby offering the double bonus of providing compile-time validation as well as XML free configuration. So enough chat lets dive in….

I created a new class library project called LcaModel.CodeFirst with the required class structure yada yada yada….

project

I then added a reference to the EntityFramework – I would normally use NuGet to do this but I wasn’t online when I wrote this post and had a copy of the necessary assembly on my machine so I copied it to my solution directory and added a reference to this assembly (EntityFramework.dll).

The code for the EfCodeFirstModule class is pretty much the same as earlier posts so I haven’t shown it but it simply tells Ninject to use the EfCodeFirstxxxxxxRepositories in the application. One thing to note is that whereas the EntityFramework implementation(see post #2) required a different version of the connection string containing details of the mapping data, CodeFirst is happy to use a generic connection string (POCS?) so I used the same one as in the last two posts. Launching the app now gave, as expected, a NotImplementedException due to the boilerplate code generated via the VisualStudio “Implement Interface” context menu option.

everything in place

As mentioned above, in CodeFirst persistence is managed via a DbContext derived class. I added a new class called EfCodeFirstContext and exposed a DbSet<T> strongly-typed to each of my POCO classes, DbSet<T> implements IQueryable<T> and is the means by which CodeFirst provides access to the persisted entities (in a real world application you would typically expose one DbSet per aggregate root). To each of my repositories I added a constructor accepting a connection string and stored this connection string in a private class level field. I then added “the code to do the things”– I’ve shown the code for EfCodeFirstBidderRepository below, as you will notice its pretty similar to the other implementations.

    7 namespace LcaModel.EfCodeFirst
    8 {
    9     public class EfCodeFirstBidderRepository : IBidderRepository
   10     {
   11         private string _connectionString;
   12 
   13         public EfCodeFirstBidderRepository(string connectionString)
   14         {
   15             _connectionString = connectionString;
   16         }
   17 
   18         public void Add(LcaModel.Bidder bidder)
   19         {
   20             using (var context = new EfCodeFirstContext(_connectionString))
   21             {
   22                 context.Bidders.Add(bidder);
   23                 context.SaveChanges();
   24             }
   25         }
   26     }
				
			
  • (This will not appear on the site)