Question

We have an ASP.Net MVC2 web site, and are utilizing EF4 for database access, etc. Being new to EF4, we have come across the EF4 POCO concept, however do not fully understand it.

In general, I’ve heard POCO defined as objects “not dependent on an external framework”. In the case of EF4, I’m guessing this means that POCO would imply somehow creating lighter-weight entities? If this is the case, what EF4 plumbing does POCO not have, what are the pros/cons of this, what extra development work might one need with POCO. In summary, when is it good to use POCO in EF4?

Answer 1

“POCO” is a vague term in the ORM space. People variously use it to mean:

• “Pure” POCOs, which do no change tracking, lazy loading, have private properties, etc. They can be challenging to work with.
• Psuedo-POCO proxies: The types with everything public virtual and which have different types at runtime.
• Self-tracking entities. Not POCOs, but not EntityObject either.

I find the “not dependent on an external framework” definition to be somewhat self-serving. It’s a way of ignoring the limitations of a framework. I.e., proxies are not real POCOs in my book, but they meet that definition.

What’s wrong with EntityObject? Not a lot. It’s fairly lightweight, and it’s part of .NET. It’s in the .NET 4 client profile, even. It doesn’t even chain you to the EF. Although it would be sort of odd to use it as a “POCO type” with a different framework, it would work just fine. It’s not in Silverlight, though, IIRC.

POCO entities are harder to work with, because you lose the stuff that EntityObject gives you for free. That’s not a lot, but something to consider before chosing POCOs just because “they’re cool,” especially for those new to the EF.

One thing that a lot of people who get religious about POCOs tend to ignore: Mapping non-POCO types in no way limits you to exposing those non-POCO types externally. Your data services can project mapped non-POCO types onto unmapped POCO DTOs and you can choose to only expose those types, i.e.:

public IEnumerable<FooDto> IFooRepository.SelectAll()
{
    return from f in Context.Foos
           select new FooDto { Id = f.Id, Name = f.Name };
}

So mapping types and data service types can easily be different concerns, if you so choose.

When doe you absolutely need non-EntityObject types for mapping? Well, if you need self-tracking entities, then that’s an open and shut case. If you must expose your mapped types to Silverlight, clearly then as well.

Beyond that it’s less clear. If you’re writing a data service for public consumption, then you should not make the DTOs be EntityObject subtypes, because that would stand in the way of plugging in a different framework later on. I would never make an immutable, public interface dependent on any one framework, even one included in .NET. On the other hand, as I said above, you can expose one type and map another; there’s no requirement to expose mapped types, ever, and often very good reasons to not expose them (perhaps they contain non-public data).