सादा ओल्ड जावा ऑब्जेक्ट (पीओजेओ) शब्द का क्या अर्थ है?

Question

शब्द सादा पुराना जावा ऑब्जेक्ट (POJO) का अर्थ क्या है? मुझे कुछ स्पष्टीकरण नहीं मिला।

POJO's Wikipedia page कहता है कि पीओजेओ एक साधारण जावा ऑब्जेक्ट है और विशेष वस्तु नहीं है। अब, जावा में विशेष क्या बनाता है या क्या ऑब्जेक्ट नहीं करता है?

उपरोक्त पृष्ठ यह भी कहता है कि पीओजेओ को पूर्व निर्धारित वर्गों का विस्तार नहीं करना चाहिए, पूर्व निर्धारित इंटरफेस को लागू करना या पूर्वनिर्धारित एनोटेशन शामिल करना चाहिए। क्या इसका यह भी अर्थ है कि पीओजेओ को इंटरफेस को Serializable, Comparable या एप्लेट्स या किसी अन्य उपयोगकर्ता द्वारा लिखित कक्षा/इंटरफेस जैसी कक्षाएं लागू करने की अनुमति नहीं है?

इसके अलावा, उपर्युक्त नीति (कोई विस्तार नहीं, कोई कार्यान्वयन नहीं) का अर्थ है कि हमें किसी भी बाहरी पुस्तकालयों का उपयोग करने की अनुमति नहीं है?

जहां पीओजेओ का उपयोग किया जाता है?

संपादित करें: अधिक विशिष्ट होने के लिए, क्या मुझे कक्षा या इंटरफेस को विस्तारित/कार्यान्वित करने की अनुमति है जो जावा या किसी बाहरी पुस्तकालय का हिस्सा हैं?

Answer 1

सादा पुराना जावा ऑब्जेक्ट :)

ठीक है, आप इसे उन की तरह ध्वनि सब भयानक प्रतिबंध नहीं कर सकते हैं।

इसका मतलब है कि जो कुछ भी पुस्तकालय/एपीआई आप के साथ काम कर रहे हैं पूरी तरह से जावा वस्तुओं है कि नहीं किया गया के साथ काम करने को तैयार है:

सामान्य संदर्भ में जहां POJO/उपयोग किया जाता है है, यह अधिक एक लाभ की तरह है किसी भी तरह से कामयाब या मनाना, यानी आपको काम करने के लिए कुछ खास करने की ज़रूरत नहीं है।

उदाहरण के लिए, एक्सस्ट्रीम एक्सएमएल प्रोसेसर (मुझे लगता है) खुशी से जावा कक्षाओं को क्रमबद्ध करता है जो Serializable इंटरफेस को लागू नहीं करते हैं। यह एक प्लस है! डेटा उत्पादों के साथ काम करने वाले कई उत्पाद आपको SomeProprietaryDataObject लागू करने के लिए मजबूर करने के लिए उपयोग करते हैं या यहां तक ​​कि AbstractProprietaryDataObject कक्षा का विस्तार भी करते हैं। कई पुस्तकालय बीन व्यवहार, यानी गेटर्स और सेटर्स की अपेक्षा करेंगे।

आमतौर पर, पीओजेओ के साथ जो कुछ भी काम करता है वह भी गैर-पीओ-जॉय के साथ काम करेगा। तो XStream निश्चित रूप से Serializable कक्षाओं serialize होगा।

Answer 2

पीओजेओ एक सादा पुराना जावा ऑब्जेक्ट है - एंटरप्राइज़ संस्करण (जे 2 ईई) सामान (बीन्स इत्यादि ...) की आवश्यकता के मुकाबले।

POJO वास्तव में एक कठिन और तेज़ परिभाषा नहीं है, और "सामान्य" गैर-एंटरप्राइज़ जावा ऑब्जेक्ट्स का वर्णन करने के एक हाथ से चलने वाले तरीके से अधिक है। बाहरी पुस्तकालय या ढांचे का उपयोग करना चाहे ऑब्जेक्ट पीओजेओ बनाता है या दर्शक की आंखों में नहीं है, जो मुख्य रूप से व्हाट्स लाइब्रेरी/फ्रेमवर्क के आधार पर होता है, हालांकि मैं अनुमान लगाता हूं कि एक ढांचा POJO

से कम कुछ कम करेगा

Answer 3

शब्द का उपयोग यह दर्शाता है कि यह आपको क्या बताना है। यदि, उदाहरण के लिए, एक निर्भरता इंजेक्शन ढांचा आपको बताता है कि आप पीओजेओ को किसी भी अन्य पीओजेओ में इंजेक्ट कर सकते हैं, जिसे वे कहना चाहते हैं कि आपको कुछ विशेष करने की ज़रूरत नहीं है: किसी भी इंटरफेस को लागू करने के लिए किसी भी अनुबंध का पालन करने की आवश्यकता नहीं है या विशेष कक्षाओं का विस्तार करें। आप जो भी पहले से प्राप्त कर चुके हैं उसका उपयोग कर सकते हैं।

अद्यतन एक और उदाहरण देने के लिए: हाइबरनेट किसी भी POJO (किसी भी वस्तु आपके द्वारा बनाई गई) एसक्यूएल टेबल, कोर डाटा में करने के लिए (iPhone पर उद्देश्य सी) मैप कर सकते हैं, जबकि अपनी वस्तुओं के लिए प्रणाली के लिए क्रम में NSManagedObject का विस्तार करने के लिए है उन्हें डेटाबेस में बने रहने में सक्षम हो। उस अर्थ में, कोर डेटा किसी भी POJO (या बल्कि POOCO = PlainOldObjectiveCObject) के साथ काम नहीं कर सकता है जबकि हाइबरनेट कर सकता है। (मैं 100% सही पुनः कोर डेटा से नहीं कर सकता क्योंकि मैंने इसे अभी शुरू करना शुरू कर दिया है। किसी भी संकेत/सुधार का स्वागत है :-))।

Answer 4

According to Martin Fowler, वह और कुछ अन्य ऊपर इसके साथ एक तरह से कुछ जो एक मानक वर्ग के रूप में करने का विरोध किया था वर्णन करने के लिए के रूप में आया एक EJB आदि

Answer 5

एक POJO के पूरे मुद्दे सादगी है और आप यह सोचते हैं होना दिखाई देते हैं ऐसा लगता है कि यह कुछ और जटिल है।

यदि कोई लाइब्रेरी POJO का समर्थन करती है, तो इसका तात्पर्य है कि किसी भी वर्ग का ऑब्जेक्ट स्वीकार्य है। इसका मतलब यह नहीं है कि पीओजेओ में एनोटेशन/इंटरफेस नहीं हो सकता है या अगर वे वहां हैं तो उनका उपयोग नहीं किया जाएगा, लेकिन यह एक आवश्यकता नहीं है।

IMHO विकी-पेज काफी स्पष्ट है। यह नहीं कहता कि पीओजेओ में एनोटेशन/इंटरफेस नहीं हो सकते हैं।

Answer 6

सादा पुराना जावा ऑब्जेक्ट नाम का उपयोग इस बात पर जोर देने के लिए किया जाता है कि किसी दिए गए ऑब्जेक्ट एक सामान्य जावा ऑब्जेक्ट है, विशेष वस्तु नहीं, जैसे कि ईजेबी 2 फ्रेमवर्क द्वारा परिभाषित किया गया है।

वर्ग एक {}
वर्ग बी फैली/लागू करता है सी {}

नोट: बी गैर POJO जब सी तरह के ढांचे के वर्ग या आईएफसी वितरित किया जाता है है। उदा। javax.servlet.http.HttpServlet, javax.ejb.EntityBean या J2EE extn और serializable/तुलनीय नहीं है। चूंकि serializable/तुलनीय POJO के लिए मान्य हैं।

यहां ए एक साधारण वस्तु है जो स्वतंत्र है। बी एक विशेष ओबीजे है क्योंकि बी सी विस्तार/कार्यान्वित कर रहा है। इसलिए बी ऑब्जेक्ट सी और बी से कुछ और अर्थ प्राप्त करता है सी और बी के नियमों का पालन करने के लिए प्रतिबंधित है वितरित ढांचे के साथ कसकर युग्मित है। इसलिए बी ऑब्जेक्ट अपनी परिभाषा से पीओजेओ नहीं है।

कक्षा ए ऑब्जेक्ट संदर्भ का उपयोग करने वाले कोड को इसके प्रकार के बारे में कुछ भी नहीं पता है, और इसका उपयोग कई ढांचे के साथ किया जा सकता है।

तो पीओजेओ को 1 नहीं होना चाहिए) पूर्व निर्धारित वर्गों का विस्तार करना और 2) पूर्वनिर्धारित इंटरफेस लागू करना।

जावाबीन पीओजेओ का एक उदाहरण है जो धारावाहिक है, इसमें कोई तर्क नहीं है, और सरल नामकरण सम्मेलन का पालन करने वाले गेटर और सेटर विधियों का उपयोग करके गुणों तक पहुंच की अनुमति देता है।

POJO पूरी तरह से व्यावसायिक तर्क पर केंद्रित है और इसकी (एंटरप्राइज़) ढांचे पर कोई निर्भरता नहीं है। इसका मतलब है कि इसमें व्यावसायिक तर्क के लिए कोड है लेकिन यह उदाहरण कैसे बनाया गया है, कौन सी सेवा (ईजेबी ..) इस ऑब्जेक्ट से संबंधित है और इसकी विशेष विशेषताएं (स्टेटफुल/स्टेटलेस) क्या हैं, इसका उपयोग करके बाहरी रूप से फ्रेमवर्क द्वारा तय किया जाएगा एक्सएमएल फ़ाइल।

उदाहरण 1: जेएक्सबी जावा ऑब्जेक्ट को एक्सएमएल के रूप में प्रस्तुत करने की सेवा है; ये जावा वस्तुएं सरल हैं और डिफ़ॉल्ट कन्स्ट्रक्टर गेटर्स और सेटर्स के साथ आती हैं।

उदाहरण 2: हाइबरनेट जहां टेबल का प्रतिनिधित्व करने के लिए सरल जावा क्लास का उपयोग किया जाएगा। कॉलम इसके उदाहरण होंगे।

उदाहरण 3: आरईएसटी सेवाएं। आरईएसटी सेवाओं में डीबी पर कुछ संचालन करने के लिए हमारे पास सर्विस लेयर और दाओ लेयर होगा। तो दाओ के पास विक्रेता विशिष्ट प्रश्न और संचालन होंगे। डीबी ऑपरेशन करने के लिए कौन सी डीएओ परत को कॉल करने के लिए सेवा परत जिम्मेदार होगी। डीएओ के एपीआई (विधियों) को बनाएं या अपडेट करें, पीओजेओ को तर्क के रूप में लेंगे, और पीओजेओ अपडेट करें और डीबी में डालें/अपडेट करें। इन पीओजेओ (जावा क्लास) में प्रत्येक कॉलम और इसके गेटर्स और सेटर्स के केवल राज्य (इंस्टेंस चर) होंगे।

प्रैक्टिस में, कुछ लोगों को टिप्पणियां सुरुचिपूर्ण लगती हैं, जबकि वे एक्सएमएल को वर्बोज़, बदसूरत और बनाए रखने के लिए कड़ी मेहनत करते हैं, फिर भी दूसरों को एनओटीशन पीओजेओ मॉडल को प्रदूषित करते हैं।

लाभ:: इस प्रकार, एक्सएमएल के लिए एक विकल्प के रूप में, कई व्यवस्थाएं (जैसे वसंत, EJB और जेपीए) की अनुमति देने के एनोटेशन बजाय या एक्सएमएल के अलावा प्रयोग की जाने वाली
बुनियादी ढांचे चौखटे से आवेदन कोड Decoupling है POJO का उपयोग करने के कई लाभों में से एक। POJO भविष्य का उपयोग करके आपके एप्लिकेशन के व्यावसायिक तर्क को अस्थिर, लगातार विकसित बुनियादी ढांचे ढांचे से डीकॉप्लिंग करके प्रमाणित किया जाता है। किसी नए संस्करण में अपग्रेड करना या एक अलग ढांचे में स्विच करना आसान और कम जोखिम भरा हो जाता है। पीओजेओ भी परीक्षण को आसान बनाता है, जो विकास को सरल बनाता है और तेज़ करता है। आपका व्यापार तर्क स्पष्ट और सरल हो जाएगा, क्योंकि यह बुनियादी सुविधाओं कोड के साथ उलझ नहीं की जाएगी

संदर्भ: wikisource2

Answer 7

एक सादा पुराना जावा ऑब्जेक्ट (POJO) है कि अपने विस्तार के लिए व्यापार तर्क के सभी शामिल हैं।

एक्सप। Pojo जो एक एकल विधि

public class Extension { 
    public static void logInfo(String message) { 
     System.out.println(message); 
    } 
} 

Answer 8

अवधि सादा पुराना जावा ऑब्जेक्ट (POJO) का क्या मतलब है शामिल हैं?

POJO मार्टिन Fowler, रेबेका पार्सन्स और जोश मैकेंज़ी द्वारा गढ़ा गया था, जब वे एक बात के लिए एक सम्मेलन में सितंबर में 2000 मार्टिन Fowler Patterns of Enterprise Application Architecture में तैयारी कर रहे थे कि कैसे एक डोमेन मॉडल जावा में पैटर्न लागू करने के लिए बताते हैं । EJB इकाई बीन्स का उपयोग करने का नुकसान में से कुछ की गणना करने के बाद:

वहाँ हमेशा जब लोग बात करते हैं के बारे में J2EE में एक डोमेन मॉडल के विकास उत्पन्न गर्मी की एक बहुत कुछ है। कई शिक्षण सामग्री और प्रारंभिक जे 2 ईई किताबें सुझाव देती हैं कि आप डोमेन मॉडल विकसित करने के लिए इकाई बीन्स का उपयोग करते हैं, लेकिन कम से कम वर्तमान (2.0) विनिर्देश के साथ इस दृष्टिकोण के साथ कुछ गंभीर समस्याएं हैं।

इकाई सेम सबसे उपयोगी होती प्रबंधित हठ (सीएमपी) कंटेनर का उपयोग कर रहे हैं ...

इकाई सेम फिर से प्रवेशी नहीं किया जा सकता। यही है, अगर आप किसी अन्य ऑब्जेक्ट में इकाई बीन से कॉल करते हैं, तो वह अन्य ऑब्जेक्ट (या कोई ऑब्जेक्ट कॉल) पहले इकाई बीन में वापस कॉल नहीं कर सकता है ...

... आप ठीक कणों का इंटरफेस के साथ दूरदराज के वस्तुओं है, तो आप भयानक प्रदर्शन ...

इकाई सेम आप एक कंटेनर और एक डेटाबेस जुड़े आवश्यकता के साथ चलाने के लिए मिलता है। यह परीक्षण समय बढ़ाएगा और परीक्षण के लिए को भी बढ़ाएगा क्योंकि परीक्षण डेटाबेस के विरुद्ध निष्पादित करना है। इकाई बीन्स डीबग करने के लिए भी मुश्किल हैं। ,

विकल्प सामान्य जावा वस्तुओं का उपयोग करना है हालांकि यह अक्सर का कारण बनता है एक आश्चर्य प्रतिक्रिया-यह आश्चर्यजनक है:

एक विकल्प के रूप में, वह नियमित जावा के लिए डोमेन मॉडल कार्यान्वयन ऑब्जेक्ट्स उपयोग करने के लिए प्रस्तावित कितने लोग सोचते हैं कि आप एक ईजेबी कंटेनर में नियमित जावा ऑब्जेक्ट्स नहीं चला सकते हैं। मैं पर आ गया हूं कि निष्कर्ष यह है कि लोग नियमित जावा ऑब्जेक्ट्स के बारे में भूल जाते हैं क्योंकि उन्हें एक फैंसी नाम नहीं मिला है। यही कारण है कि, 2000 में रीबका पार्सन्स, जोश मैकेंज़ी, और मैंने उन्हें एक बात की तैयारी करते समय, पीओजेओ (सादे पुरानी जावा ऑब्जेक्ट्स)। एक POJO डोमेन मॉडल एक साथ रखना आसान है, ईजेबी कंटेनर के बाहर बनाने, चलाने और परीक्षण करने के लिए त्वरित है, और ईजेबी से स्वतंत्र है (शायद यही कारण है कि ईजेबी विक्रेता आपको का उपयोग करने के लिए प्रोत्साहित नहीं करते हैं)।