What are essential differences between the different code generation items for EDMX model?

Question

I\'m trying to ramp up on the entity framework so I don\'t feel like I\'m in the dark ages. I tried (and have thus far failed) to intuit from generated code what the essential

Answer 1

POCO Generator

POCO stands for Plain Old C# (or CLR) Object. POCOs are independent on EF. They are just classes following some rules but you can inherit them from your own type if you want. They also don't include any persistence dependent data.

Currently this type is most popular because it is trend of current architecture approaches to have everything POCO and lightweight. In some situations using POCOs is more complex but that is a price for persistence ignorant architecture.

EntityObject Generator

This generator produces the same type of entities as the default code generation method for EDMX. These entities derive from EntityObject class which makes them fully dependent on Entity framework (I call them heavy entities). This dependency offers them some additional features or simplifications but it makes them harder to use in detached scenarios and their usage leads either to architecture with tight coupling of upper layers to Entity framework or to additional complexities when achieving better separation.

This type of entities was the only type supported in the first EF version. Even everybody is using POCOs to achive better separation this type is native for EF and probably offers most features.

This generator also makes your entities serializable (with DataContractSerializer).

Self tracking entities (STE) Generator

This is very special type of POCO generator. When working with EF we differ two scenarios. Attached scenarion where EF tracks changes made to entity and detached scenario where you did changes outside of EF scope and once you attached entity to EF you must tell it what changes you did. Typical detached scenarios are web services where you pass entities to the client and once the client passes them back you must somehow synchronize changes so that EF knows what SQL commands it must generate. STEs are for these detached scenarios. They are implementation of change set pattern = they track their current state as well as changes made since self tracking started (as old DataSet did).

This is a theory. In the real world STEs have some big disadvantages and are suitable only for very specific scenarios.

Edit:

There is one more generator which is installed together with Entity Framework 4.1.

DbContext Generator

This generator leads to the same entities as POCO generator. The only difference is used API. POCO generator uses ObjectContext API whereas DbContext generator uses POCOs with DbContext API (only available in EF 4.1 and June 2011 CTP). The difference between these APIs is matter of choice.