Zum Inhalt springen

„Plain old CLR object“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
[ungesichtete Version][ungesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
Keine Bearbeitungszusammenfassung
Removed broken ref tag which encompassed a broken link
Zeile 1: Zeile 1:
{{Redirect|POCO||Poco (disambiguation)}}
{{Redirect|POCO||Poco (disambiguation)}}
'''Plain Old [[Common Language Runtime|CLR]] Object''' or '''POCO''' is a play on the term [[Plain Old Java Object|POJO]], from the [[Java Platform, Enterprise Edition|Java EE]] programming world (which was coined by Martin Fowler in 2000 <ref>See anecdote here: http://www.marti
'''Plain Old [[Common Language Runtime|CLR]] Object''' or '''POCO''' is a play on the term [[Plain Old Java Object|POJO]], from the [[Java Platform, Enterprise Edition|Java EE]] programming world (which was coined by Martin Fowler in 2000
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 [[object-relational mapping|ORM]] systems usually generate. Another way to put it is that POCOs are objects unencumbered with inheritance or attributes needed for specific frameworks <ref> See, for example, this MSDN article: [http://msdn.microsoft.com/en-us/library/cc681329.aspx Data Contracts - POCO Support]</ref> 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 [[Microsoft Transaction Server|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 [[Ejb#Legacy|EJB2]].
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 [[object-relational mapping|ORM]] systems usually generate. Another way to put it is that POCOs are objects unencumbered with inheritance or attributes needed for specific frameworks <ref> See, for example, this MSDN article: [http://msdn.microsoft.com/en-us/library/cc681329.aspx Data Contracts - POCO Support]</ref> 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 [[Microsoft Transaction Server|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 [[Ejb#Legacy|EJB2]].



Version vom 30. April 2015, 11:29 Uhr

Vorlage:Redirect 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 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 [1] 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,<ref>See, for example, a reference to PONO in this whitepaper: [http://www.springframework.net/doc-latest/reference/pdf/spring-net-reference.pdf Spring Some benefits of POCO objects are:

  • Allows a simple storage mechanism for data, and simplifies serialization/passing data through layers.
  • Goes hand-in-hand with dependency injection, and the repository pattern.
  • Minimized complexity and dependencies on other layers (higher layers only care about the POCOs, POCOs don't care about anything) which facilitates loose coupling.
  • Increases testability through simplification.

See also

References

  1. See, for example, this MSDN article: Data Contracts - POCO Support

Vorlage:Comput-lang-stub