Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
“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.)