Content deleted Content added
→Transparently adding services: dab CDI |
first, last |
||
Line 1:
In [[software engineering]], a '''plain old Java object''' ('''POJO''') is an ordinary [[Java_(programming_language)|Java]] [[Object (computer science)|object]], not bound by any special restriction and not requiring any class path. The term was coined by [[Martin Fowler]], Rebecca Parsons and Josh MacKenzie in September 2000: <ref name="bliki" />
<blockquote>
"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."<ref name="bliki">{{cite web |url=http://www.martinfowler.com/bliki/POJO.html |title=MF Bliki: POJO |work=MartinFowler.com }}</ref>
</blockquote>
The term "POJO" initially denoted a Java object which does not follow any of the major Java object models, conventions, or frameworks; nowadays "POJO" may be used as an acronym for "Plain Old ''JavaScript'' Object" as well, in which case the term denotes a [[JavaScript]] object of similar pedigree.<ref>{{cite web |url=http://ajaxian.com/archives/return-of-the-pojo-plain-ole-javascript |title=Return of the POJO: Plain ‘Ole JavaScript |date=2006-07-17 |accessdate=2014-08-19 }}
</ref>
The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS ([[Plain Old Telephone Service]]) in [[telephony]] and Pod ([[Plain Old Documentation]]) in [[Perl]]. The equivalent to POJO on the [[.NET framework]] is [[Plain Old CLR Object]] (POCO).<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/cc681329.aspx |title=POCO Support |work=microsoft.com |accessdate=2012-05-27 }}
</ref> For [[PHP]], it is Plain Old PHP Object (POPO).<ref>{{cite web |url=http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |title=typesafe objects in PHP |first=Jan |last=Kneschke |date=2007-02-19 |work=kneschke.de |accessdate=2012-05-27 }}</ref><ref>{{cite web |url=http://jym.sg/controller-with-bare-bone-plain-old-php-objec |title=Controller with bare-bone Plain Old PHP Object aka POPO |
▲{{cite web |url=http://jym.sg/controller-with-bare-bone-plain-old-php-objec |title=Controller with bare-bone Plain Old PHP Object aka POPO |author=Jym Cheong |date=2011-06-26 |work=jym.sg |accessdate=2012-05-27}}
</ref>
Line 59 ⟶ 55:
===Transparently adding services===
As designs using POJOs have become more commonly used, systems have arisen that give POJOs the full functionality used in frameworks and more choice about which areas of functionality are actually needed. In this model, the programmer creates nothing more than a POJO. This POJO purely focuses on [[business logic]] and has no dependencies on (enterprise) frameworks. [[Aspect-oriented programming]] (AOP) frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.<ref name="Martin2008">Martin, Robert C
[[Spring Framework|Spring]] was an early implementation of this idea and one of the driving forces behind popularizing this model.
Line 92 ⟶ 88:
</syntaxhighlight>
In practice, some people find annotations elegant, while they see XML as verbose, ugly and hard to maintain, yet others find annotations pollute the POJO model. <ref>Panda, Debu; Rahman, Reza; Lane
Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead of or in addition to XML. The following shows the same EJB bean as showed above but with an annotation added. In this case the XML file is no longer needed:
Line 106 ⟶ 102:
</syntaxhighlight>
With the annotation as given above the bean isn't a truly pure POJO anymore, but since annotations are merely passive metadata this has far fewer harmful drawbacks compared to the invasiveness of having to extend classes and/or implement interfaces.<ref
==See also==
Line 114 ⟶ 110:
==References==
{{Reflist}}
[[Category:Computing acronyms]]
| |||