What can I use POCO for?

Question

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?

Answer 1

POCO is just "Plain Old CLR Object". It's just a standard class, any standard class.

In terms of EF, people are referring to being able to configure EF to store your own classes (not generated directly by EF) into the database.

Answer 2

POCO are classes designed to transfer data within your application (i.e. move data from the data layer to the ui layer). They also decouple the structure of your application from the schema of your database.

On small projects this isn't a big deal, but as the project grows the object model (how you design your POCOs) tends to stray from the database schema.

Other methods that are typically used in .Net are DataTables and DataSets. Typically the the data is retrieved by using the column name. This couples you do the column name in your database. If the column name changes in the database you code breaks.

Answer 3

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.

Answer 4

POCO is just a normal class, with no added interfaces or base classes to make it work with your database layer (in this context).

Advantage are: 1) no dependencies on that particular database layer, so you could swap it out for a better one (i.e. NHibernate) without ever having to modify anything other than the database layer.

2) it makes it easier to unit test your classes.

3) no boiler plate code to notify when a property has changed etc. just plain getters and setters.

Idealy your domain objects are loaded from the ORM, without that object having to have any say in how it's loaded, how changes are tracked or how it is saved etc.

NHibernate does a very good job at this, the only requirement is that you have to make all properties/methods virtual, this is a whole lot better than any hard dependency.