Entity Framework 4.0: Why Would One Use the Code Generated EntityObjects Over POCO Objects?

Aside from faster development time (Visual Studio 2010 beta 2 has no T4 templates for building POCO entity objects that I'm aware开发者_Go百科 of), are there any advantages to using the traditional EntityObject entities that Entity Framework creates, by default? If Microsoft delivers a T4 template for building POCO objects, I'm trying to figure out why anybody would want to use the traditional method.

---

You're asking two questions at the same time, it seems. Code-only versus model-first and EntityObject parent type versus arbitrary parent type. You get designer support with model-first, regardless of parent type. Aside from designer support, you can also use precompiled views with model-first. That can significantly help performance.

Having EntityObject as a parent can be an advantage over so-called "POCOs" (which are usually proxy bases, not "plain" objects), because the runtime type of your entities are the exact type you expect, rather than a runtime-generated subtype.

Also, unlike other ORMs which have minimal to no LINQ support, the Entity Framework has rich LINQ support, allowing you to project onto real POCO types. Therefore, it is possible to build truly persistence-ignorant presentations without having to care about what the base type of your entities are. You are not stuck with whatever type comes out of the ORM blackbox.

EntityObject allows for private properties which are persisted to the database. Using proxy types requires that those properties are at least protected and must be virtual. Therefore, EntityObject may allow for better encapsulation.

I'm not trying to suggest, by the way, that there aren't advantages to using proxies; I'm just trying to answer your question about what the advantages of EntityObject are.

---

I think the only benefit is designer support. Can't find any other benefits in using non-poco entities.