Why are POCO's a good thing in relation to EF4, nHiberate

Question

Why is it so important to support POCO's in EF4, Linq2SQL or any other data mapping technologies? I understand the concept of a POCO in the OO sense but is there something else I'm missing when it comes to ORM's?

EDIT: I'm just adding my personal definition of a POCO in the context of ORM's: It is a class that is hand-coded by the developer as opposed to a class that is generated, augmented or annotated by a ORM mapping tool (like Visual Studio's EF4 designer).

Please correct me if I'm wrong.

Answer 1

"POCO" means the framework places no unnecessary or counterintuitive constraints on the entity objects – no need to use a code generator, no need to extend a framework-provided base class, extensively annotate properties, or to have to, for the most part, write different code than you would were the classes always stored in-memory. This keeps the concern of persisting data outside the model classes and reduces cognitive overhead.

Compare the POCO definitions from NHibernate or EF Code First with the code Visual Studio generates for EF without Code First and ask yourself which one you prefer to read and maintain. (When poking around a new codebase for instance.)

Answer 2

Usually you don't want your code to depend on a certain ORM technology. POCOs minimize that dependency. It's just one incarnation of the general principle of decoupling.