StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>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 <b>plain</b> 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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx" rel="noreferrer">addon frameworks</a> that attempt to add POCO support to the EF, but I don't know how successful they are. The <a href="http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx" rel="noreferrer">EF in .net 4.0</a> will have POCO support.</p> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload