Jump to content

Plain old CLR object

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 38.98.148.66 (talk) at 17:14, 29 August 2014 (Deleted the comment about little or no code in POCOs because this is a common misconception. In fact, if there is little or no code, you likely have an anemic domain. Testing is simpler because there are no 3rd party dependencies.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Plain Old CLR Object or POCO is a play on the term POJO, from the Java EE programming world (which was coined by Martin Fowler in 2000 [1]), and is used by developers targeting the Common Language Runtime of the .NET Framework. Simply put, a POCO object does not have any dependency on an external framework. It is PLAIN.

Similar to the Java context, the term is used to identify an object as a simple object, as opposed to the complicated, specialized objects that frameworks like ORM systems usually generate. Another way to put it is that POCOs are objects unencumbered with inheritance or attributes needed for specific frameworks [2] and are persistence ignorant objects. In .NET terms, the word is most often used in the programmatic sense, to differentiate a non-Serviced Component (see MTS) from a "standard object". It can also be used in a tongue-in-cheek manner, referencing the perceived complexity and invasiveness of Java-based programming frameworks such as the legacy EJB2.

POCO is often incorrectly expanded to Plain Old C# Object, but POCOs can be created with any language targeting the CLR. An alternative acronym sometimes used is PONO,[3] for Plain Old .NET Object.

Some benefits of POCO objects are:

  • Allows a simple storage mechanism for data, simplifies serialization/passing around through layers.
  • Goes hand in hand with depedency injection, and the repository pattern.
  • Minimized complexity and dependencies on other layers. (higher layer's only care about the POCO's, POCO's don't care about anything). Loose coupling.
  • Simple testability.

See also

References

  1. ^ See anecdote here: http://www.martinfowler.com/bliki/POJO.html
  2. ^ See, for example, this MSDN article: Data Contracts - POCO Support
  3. ^ See, for example, a reference to PONO in this whitepaper: Spring.net Reference Documentation

Template:Comput-lang-stub