"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).