Why POCO is a Good Thing Regarding EF4, nHiberate

Question

Why is it so important to support POCO in EF4, Linq2SQL or any other data mapping technology? I understand the concept of POCO in the sense of OO, but is there anything else that I am missing when it comes to ORM?

EDIT: I just add my personal POCO definition in the context of ORM : This is a class that is manually encoded by the developer, and not a class that is generated, supplemented, or annotated by the ORM mapping tool (e.g. Visual Studio EF4 designer).

Please correct me if I am wrong.

Answer 1

"POCO" means that the structure does not create unnecessary or contradictory restrictions for entity objects - there is no need to use a code generator, there is no need to extend the base class provided by the infrastructure, annotate properties widely or have for the most part, write different code than the classes would be, always stored in memory. This remains a concern for storing data outside the model classes and reduces cognitive overhead.

Compare POCO definitions from NHibernate or EF Code First, with Visual Studio code generated for EF without First code, ask yourself which one do you prefer to read and maintain. (For example, when you write a new code base.)

Answer 2

Normally you do not want your code to depend on a particular ORM technology. POCOs minimize this dependency. This is just one embodiment of the general principle of decoupling.

Answer 3

Entity Framework allows you to use custom data classes with your data model without making any changes to the data classes themselves.

This means that you can use the "plain old" CLR (POCO) objects, such as existing domain objects, with your data model. These POCO data classes, which are mapped to objects that are defined in the data model, support most of the same queries, insert, update, and delete behavior in the form of object types that are generated by entity data model tools.