I have read some articles on POCO in the enttity framework but still don’t understand what I can use it for. How can POCO benefit my projects?
Share
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.
I have read some articles on POCO in the enttity framework but still don’t understand what I can use it for. How can POCO benefit my projects?
POCO standards for “Plain Old Clr Object”. It refers to a style of ORM architecture where all the work for persisting and loading the data from the data store is done by the system with out the object itself knowing what is happening to it. This means that the ORM can support totally plain objects that haven’t been modified in any way with the ORM in mind. An ORM that supports persistence of POCOs won’t require you to have your class inherit from any specific base, implement any interface, or even tag methods with any attributes.
The complete opposite of this (sometimes known as Data Access Objects – or DAO) is when all of the storage is handled by the object itself, it knows exactly how to serialize and store itself and how to load itself when required. In this case the objects should be used purely to transfer the data and should not represent any of the business logic of the system.
In reality this is more of a spectrum with these two situations at either end. Many ORMs sit somewhere in the middle, requiring persistence to be handled externally to the class, but often also requiring some metadata or interfaces being implemented on the classes being persisted to help things along.
The EF (v1) does not support POCOs. The objects must implement various interfaces (to provide notification of property values changes etc) in order to be persistable by the framework. I believe there are addon frameworks that attempt to add POCO support to the EF, but I don’t know how successful they are. The EF in .net 4.0 will have POCO support.
POCO is often considered good because it allows for a strong separation of concerns. You can define your data objects to have absolutely zero knowledge of the mechanism that will be used to store them. (So it makes it easy to switch out the storage mechanism for something different in the future). It also means you don’t have to design your data objects with any consideration for the database/framework that is used to store them.