I've been a big Hibernate user over the years, and I've really got used to the ease of development and the way that Hibernate insulates me form the underlying database.  Over the years I've had a few occasions to port databases and the Data Access Object has always stood me in good stead, in particular the Generic DAO, which acts as the CRUD layer for all my queries.  Hibernate makes it incredibly easy to do, and the persistence ignorance and Session management mean I can really make the domain model completely unaware of the persistence scheme.

So next week I'm talking about the Entity Framework and patterns at DevWeek, and as I use the DAO pattern so much I thought I'd implement it in the EF.  And after tearing my hair out for a few hours today, I can safely say that although there are some bits of the EF I really like, the context management and lack of persistence ignorance are real downers.

Anyway here goes:

I basically started off creating my usual CRUD interface, but there are a few wrinkles.  I really should have used IPOCO, and I probably will in the future, but for now I just made sure that all my generic types are constrained to be subtypes of EntityObject, giving an interface like:

public interface GenericDAO<TEntity> where TEntity : EntityObject 
  
{  
    TEntity Create(TEntity entity);  
    TEntity Delete(TEntity entity);  
    TEntity Update(TEntity entity);  
    List<TEntity> FindAll();  
    void Clear(); 

}

I'm a bit unhappy about exposing the EntityObject to the business layer, but I spent too many years with EJBs making Data Transfer Objects (DTOs) to even contemplate using them.  I started out using Microsoft's quaintly named IPOCOs.  But after I had to implement 3 interfaces and manually do all the change tracking, I nearly threw the laptop at the wall.  There are some efforts to make it a bit easier by using code generation and Postsharp and you can read Ruurd Boekes blog here.  But to be honest, you can't polish a ...

The implementation of the CUD methods were fairly straightforward.  To illustrate I'll start by showing the constructor and the Create method.

public EFGenericDao(string containerName, string entitySet, string connectionString) 
{
         this._containerName = containerName;  
         this._entitySet = entitySet;  
         this._connectionString = connectionString;  
         this._fullEntitySetName = containerName + "." + entitySet;
} 

public virtual TEntity Create(TEntity entity)
{     
   using (ObjectContext ctx = new ObjectContext(_connectionString))
   {     
     ctx.AddObject(_fullEntitySetName, entity);
      ctx.SaveChanges();
   } 
   return entity;
}

As I'm going to use ObjectContext rather than the code generated context that the EDM designer gives me, you need to pass in the connection string, entity container name and the entity set that contains the entities you want to work with.  The Create is very straightforward, simply add the object to the context and then commit using SaveChanges.

Delete and Update are a little more nasty, although you could avoid my nasty little refresh from the database if you set the EntityKey and called attach to add the object into the context.  I chose the easy way out, I simply load the object into the context from the database and then delete or update as appropriate.

public TEntity Update(TEntity entity)  
{

    using (ObjectContext ctx = new ObjectContext(_connectionString))

    {

        object entityToUpdate = GetObjectByKey(entity.EntityKey);

        if (entityToUpdate != null)

        {

            ctx.ApplyPropertyChanges(_fullEntitySetName, entity);

        }

    }

    return entity;

}