Entity framework POCO

What does one loose by creating POCO us开发者_Python百科ing T4 templates in entity framework 4.0? Why is the default behavior when using entity framework 4.0 not to create POCO?

You lose a number of things. A "pure" POCO is of limited use in an ORM, because it will not do change tracking. In other words, when you mutate the object and then save changes to the context, you would like the changed properties saved to the database. With a "pure" POCO you can do this with snapshot based change tracking, which is fairly inefficient. You can also do it with runtime proxies, which force you to make your track properties public virtual, so you arguably don't have a "POCO" anymore. Also, using proxies means that you don't know the true runtime type of the instance.

You also lose some of the convenience properties like EntityState.

"Pure" POCOs cannot do lazy loading. Again, you can work around this with proxy types, but, again, if you're using proxies, you don't really have a "pure" POCO.

On top of all of this, there is less need to use POCO entities in the Entity Framework than in some other ORMs. This is because you can always project your entity types onto POCO instances using LINQ, without having to materialize the entity instances first. So "pure" POCOs are always available in an Entity Framework application, even if you don't happen to map your entities that way.