Entity Framework 4.0: POCO or POCO?

The Entity Framework shipping with .NET Framework 4.0 is a major improvement over .NET Framework 3.5 SP1 Entity Framework, which was the first version.  The first version was a nice curiosity but had many shortfall.  For instance, it didn’t support stored procedures, the designer wasn’t flexible, the produced ad hoc queries were quite hard to read, etc. .

EF 4.0 improved on all those fronts.  It is now a very usable Framework and I recommend it.

EF 4.0 also comes with POCO support.  The default usage of EF 4.0 (and EF 3.5 SP1 for that matter) generates entities which are derived from EntityObject and stuffed with attributes.  POCO on the hand lets you generate entities that are Plain Old CLR Objects (POCO).

Now, if you’re like me and you follow Scott Gu’s blog, you might have read an entry about Code-First development in Entity Framework and labelled it “POCO” in your mind.  The blog entry goes on saying it’s in CTP while the other POCO you’ve heard about shipped with .NET Framework 4.0.  What is the difference between those two technologies?

Well…  Many, but they might not impact you all.

Let’s look at the POCO support of EF 4.0.  In order to use that today, you need to change the code generation strategy on your model.  On the EF designer surface, pop the context-menu and select Add Code Generation Item.

 

This will bring you to an empty Add Item dialog box.  Go to the online template and download the ADO.NET C# POCO Entity Generator:

 

This will download a T4 template on your box.  This generates a slightly different set of classes.  Basically the object-context is similar but the entity sets are POCOs instead of deriving from EntityObject.

That’s it.  That’s what POCO offers you today.

Now what are the drawbacks of that technology?  The main drawback is that the entities are still generated.  So if you would like to use objects provided to you (e.g. WCF data contracts), this mechanism isn’t useful to you.

Now, if you play with the code generated a little you’ll see you can generate it yourself and therefore you fall pretty close to what Code-First development has to offer.

That is if you play with single tables with no relation.  Once you start putting tables with relations you start seeing those FixUp code popping around.  Basically, the management of items in collection isn’t exactly trivial and frankly, it’s a bit messy.  Just have a look of this antic, generated for you:

public class FixupCollection<T> : ObservableCollection<T>
{
    protected override void ClearItems()
    {
        new List<T>(this).ForEach(t => Remove(t));
    }

    protected override void InsertItem(int index, T item)
    {
        if (!this.Contains(item))
        {
            base.InsertItem(index, item);
        }
    }
}

Basically, the Entity Framework was designed on the foundation that entities were tracking themselves.  Once you start introducing POCOs, you remove that foundation and not surprisingly, the building starts to shake.

But not everything is lost, Code-First EF comes in.  With Code-First, you really get your POCO classes.  To take the examples given by Scott on his blog, here’s how your entities look like:

This is how the object-context looks like:

Now, that is POCO!

You might have notice that some classes have changed.  Instead of ObjectContext we have DbContext and instead of ObjectSet we have DbSet.  Basically, those classes redo the foundation the other POCO Framework was missing.

Now development-first doesn’t stop there.  You don’t need a mapping XML-file with this Framework.  By default, it uses convention (convention over configuration) to map your objects to tables and columns.  So if you have a table Dinner and an object Dinner, you don’t need to configure anything.  If your object context has the same name than the connection string in your web / app.config, you don’t even need to plug the two together.  Like magic!

Actually, a bonus is that the connection string doesn’t need to be an EF connection string with your SQL connection string embedded in it.  That alone is something!

You can actually have the DB schema generated from your Db-context.  Magic, I told you.

What can you do if your object-model doesn’t map exactly to your DB?  Well, you have to use an API (I don’t know if you can use the mapping file with code-first).  You actually can also annotate your POCO objects.

Now code-first is in CTP.  The fourth CTP was released in July 2010.  They are looking for a vehicle to ship it…  Maybe an SP1 of the Framework?

If you look at all of this, it seems like EF is changing.  The mapping file is slowly fading away, being replaced by an API, new annotation comes in, all the base classes change…  On the other hand, when you use it, it’s pretty much the same.

For me I’ll wait before I use code-first on a real projects.

Here are some resources:

• Conventions on Code-First
• Data Annotation on Code-First
• MSDN article about Code First by Julie Lerman, October 2010
• Article by Scott Hansleman on Code First