मैं अपना प्रोजेक्ट Google App Engine पर Struts2 के साथ विकसित करना चाहता हूं। डेटाबेस के लिए मेरे पास दो विकल्प हैं जेपीए और जेडीओ। क्या तुम लोग मुझे इस पर सुझाव दोगे? दोनों मेरे लिए नए हैं और मुझे उन्हें सीखने की जरूरत है। इसलिए मैं आपके उत्तरों के बाद एक पर ध्यान केंद्रित करूंगा।
धन्यवाद।
जवाबों:
JPA दृढ़ता के लिए सूर्य का मानक है, JDO IMHO मर रहा है (वास्तव में, यह मर चुका है लेकिन अभी भी चल रहा है)। दूसरे शब्दों में, जेपीए दीर्घावधि में एक बेहतर निवेश है। इसलिए मुझे लगता है कि अगर दोनों मेरे लिए नए होते तो मैं जेपीए को चुनता।
जीएई / जे गूगल समूह में इस बहुत सी बात के बारे में कई पोस्ट हैं। मैं वहां एक खोज करूंगा और लोगों की राय देखूंगा। ऊपर व्यक्त की गई राय के लिए आपको एक बहुत अलग संदेश मिलेगा। इस तथ्य पर भी ध्यान दें कि बिगटेबल आरडीबीएमएस नहीं है। इस काम के लिए सही उपकरण का उपयोग करें
सिर्फ डेटा न्यूक्लियस द्वारा जेपीए और जेडीओ के बीच इस तुलना को स्वयं देखा: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html एक आंख खोलने वाला।
मैं JDO का एक खुश उपयोगकर्ता हूँ। अच्छा काम करते रहो दोस्तों।
जेडीओ के मृत होने का दावा करने वाले लोग योग्यता के बिना नहीं हैं। यहाँ मैं प्रो ईजेबी 3 जावा पर्सिस्टेंस एपीआई पुस्तक में पढ़ा गया हूं: "इसके तुरंत बाद सन ने घोषणा की कि जेडीओ को विनिर्देश रखरखाव मोड में कम किया जाएगा और जावा पर्सिस्टेंस एपीआई जेडीओ और अन्य दृढ़ता विक्रेताओं दोनों से आकर्षित होगा और एकल समर्थित बन जाएगा। मानक आगे बढ़ रहा है। " लेखक माइक कीथ EJB3 पर सह-विनिर्देश नेता हैं। बेशक वह जेपीए का बड़ा समर्थक है, लेकिन मुझे संदेह है कि वह झूठ बोलने के लिए पर्याप्त पक्षपाती है।
यह सच है कि जब पुस्तक प्रकाशित हुई थी, तो ज्यादातर प्रमुख विक्रेता JDO के बजाय JPA के पीछे एकजुट थे, भले ही JDO में JPA की तुलना में अधिक उन्नत तकनीकी विशेषताएं हैं। यह आश्चर्य की बात नहीं है क्योंकि ईबी दुनिया में बड़े खिलाड़ी जैसे आईबीएम / ओरेकल भी बड़े आरडीबीएमएस विक्रेता हैं। अधिक ग्राहक अपनी परियोजनाओं में गैर-आरएमबीएस की तुलना में आरडीएमबीएस का उपयोग कर रहे हैं। जब तक जीएई ने इसे बढ़ावा दिया तब तक जेडीओ मर रहा था। यह समझ में आता है क्योंकि जीएई डेटा स्टोर रिलेशनल डेटाबेस नहीं है। JPA की कुछ विशेषताएं बड़ी संगति के साथ काम नहीं करती हैं जैसे एकत्रीकरण प्रश्न, कई प्रश्नों के स्वामित्व वाले कई प्रश्न। BTW, GAE JDO 2.3 का समर्थन करता है जबकि केवल JPA 1.0 का समर्थन करता है। यदि आपका लक्ष्य क्लाउड प्लेटफ़ॉर्म है तो मैं JDO को सिफारिश करूंगा।
रिकॉर्ड के लिए, यह Google App Engine (GAE) है, इसलिए हम Google नियमों के साथ खेलते हैं जो Oracle / Sun नियमों के साथ नहीं हैं।
इसके तहत, जेपीए जीएई के लिए उपयुक्त नहीं है, यह अस्थिर है और यह अपेक्षा के अनुरूप काम नहीं करता है। न तो Google इसका समर्थन करने को तैयार है लेकिन नंगे न्यूनतम।
और अन्य भाग के लिए, JDO GAE में काफी स्थिर है और यह (कुछ विस्तार में) Google द्वारा अच्छी तरह से प्रलेखित है।
हालाँकि, Google उनमें से किसी की भी सिफारिश नहीं करता है।
http://code.google.com/appengine/docs/java/datastore/overview.html
निम्न-स्तरीय API सर्वश्रेष्ठ प्रदर्शन देगा और GAE सभी प्रदर्शन के बारे में है।
उदाहरण के लिए, 10 इकाई जोड़ें
अजगर: 68 मी
JDO: 378ms
जावा मूल निवासी: 30ms
जेडीओ बनाम जेपीए के बीच की दौड़ में मैं केवल डेटान्यूक्लियस के पोस्टर से सहमत हो सकता हूं।
सबसे पहले, और सबसे महत्वपूर्ण बात, डेटान्यूक्लियस के पोस्टर जानते हैं कि वे क्या कर रहे हैं। वे सभी एक सतत पुस्तकालय विकसित करने के बाद हैं और डेटा मॉडल से संबंधित हैं जैसे कि रिलेशनल, जैसे बिग टेबल। मुझे यकीन है कि आईडी हाइबरनेट के लिए एक डेवलपर यहां थे, उन्होंने कहा था: "जब हमारे कोर लाइब्रेरीज़ का निर्माण हमारी सभी मान्यताओं को संबंधपरक मॉडल से कसकर जोड़ा जाता है, तो हाइबरनेट जीएई के लिए अनुकूलित नहीं है"।
दूसरे, जेपीए निर्विवाद रूप से अधिक व्यापक उपयोग में है, आधिकारिक जावा ईई स्टैक का एक हिस्सा होने से थोड़ी मदद मिलती है, लेकिन इसका मतलब यह नहीं है कि यह बेहतर है। वास्तव में, जेडीओ, यदि आप इसके बारे में पढ़ते हैं, तो जेपीए की तुलना में उच्च स्तर के अमूर्त स्तर से मेल खाती है। JPA को कसकर RDBMS डेटा मॉडल के साथ जोड़ा गया है।
प्रोग्रामिंग स्टैंड पॉइंट से, JDO API का उपयोग करना एक बेहतर विकल्प है, क्योंकि आप वैचारिक रूप से बहुत कम समझौता कर रहे हैं। आप अपनी इच्छा के किसी भी डेटा मॉडल के लिए सैद्धांतिक रूप से स्विच कर सकते हैं, बशर्ते आप जिस प्रदाता का उपयोग करते हैं वह अंतर्निहित डेटाबेस का समर्थन करता है। (व्यवहार में आप शायद ही कभी उच्च स्तर की पारदर्शिता प्राप्त करते हैं, क्योंकि आप अपने आप को जीएई की वस्तु पर अपनी प्राथमिक कुंजी सेट कर पाएंगे और आप अपने आप को एक विशिष्ट डेटाबेस प्रदाता, जैसे कि Google से बांधेंगे)। हालांकि यह अभी भी स्थानांतरित करना आसान होगा।
तीसरा, आप हाइबरनेट, ग्रहण लिंक और यहां तक कि जीएई के साथ वसंत का उपयोग कर सकते हैं। लगता है कि Google ने आपके अनुप्रयोगों के निर्माण के लिए आपके द्वारा उपयोग किए जाने वाले चौखटे का उपयोग करने के लिए एक बड़ा प्रयास किया है। लेकिन जब लोग अपने जीएई अनुप्रयोगों का निर्माण करते हैं तो उन्हें एहसास होता है जैसे कि वे आरडीबीएमएस पर चल रहे थे। जीएई पर वसंत धीमी है। आप इस विषय पर Google IO वीडियो को देख सकते हैं कि यह सत्य है।
इसके अलावा, मानकों का पालन करना एक अच्छी समझदारी की बात है, सिद्धांत रूप में मैं सराहना करता हूं। दूसरी ओर, जेपीए जावा ईई स्टैक का हिस्सा होता है, जो कई बार लोगों को विकल्पों की धारणा खो देता है। एहसास, अगर आप करेंगे, कि जावा सर्वर चेहरे भी जावा ईई स्टैक का हिस्सा है। और यह वेब GUI विकास के लिए अविश्वसनीय रूप से स्पष्ट समाधान है। लेकिन अंत में, लोग, होशियार लोग अगर मैं ऐसा कह सकता हूं, तो इस मानक से भटकें और इसके बजाय GWT का उपयोग करें?
इस सब में, मुझे यह कहना होगा कि जेपीए के लिए एक बहुत महत्वपूर्ण बात है। यह जेपीए के लिए Guice और इसका सुविधाजनक समर्थन है। लगता है कि Google इस बिंदु में हमेशा की तरह स्मार्ट नहीं था और अभी तक JDO का समर्थन नहीं करने के लिए संतुष्ट है। मुझे अब भी लगता है कि वे इसे बर्दाश्त कर सकते हैं, और आखिरकार जूस जेडीओ को भी साथ ले जाएगा, ... या शायद नहीं।
मुझे लगता है JDOकि यह लिखने के समय का उपयोग करने के बारे में भयानक है कि केवल कार्यान्वयन विक्रेता है Datanucleusऔर उस की कमियां प्रतियोगिता की कमी है जो कई मुद्दों की ओर ले जाती है जैसे:
extensionsStackOverflowमैं हमेशा किसी से उम्मीद कर रहा हूं कि वह JDOखुद ही विनिर्देश को लागू करना शुरू कर दे, हो सकता है कि वे कुछ और पेश करें और उम्मीद से अधिक मुक्त समुदाय पर ध्यान दें और हमेशा समर्थन के लिए भुगतान करने के बारे में परेशान न हों, यह कहते हुए कि Datanucleusलेखक केवल व्यावसायिक समर्थन की परवाह नहीं करते हैं , लेकिन मैं सिर्फ कह रहा हूं।
मैं व्यक्तिगत रूप से विचार करता हूं कि Datanucleusलेखकों का कोई दायित्व नहीं Datanucleusहै और न ही यह समुदाय है। वे किसी भी समय पूरे प्रोजेक्ट को गिरा सकते हैं और कोई भी उन्हें इसके लिए जज नहीं कर सकता, यह उनका प्रयास है और उनकी खुद की संपत्ति है। लेकिन आपको पता होना चाहिए कि आप क्या कर रहे हैं। आप देखें, जब हममें से कोई एक डेवलपर उपयोग करने के लिए एक ढाँचे को देखता है, तो आप उस रूपरेखा के लेखक को दंडित या आज्ञा नहीं दे सकते, लेकिन दूसरी ओर, आपको अपना काम पूरा करने की आवश्यकता है! यदि आपके पास उस रूपरेखा को लिखने का समय है, तो आप पहले स्थान पर क्यों देखेंगे?
दूसरी ओर, JDOअपने आप में कुछ जटिलताएँ हैं जैसे कि वस्तुओं का जीवन चक्र और सामान जो बहुत सहज और सामान्य नहीं है (मुझे लगता है)।
संपादित करें: अब मुझे पता है JPAकि वस्तु जीवन चक्र तंत्र को भी लागू करता है, इसलिए यदि आप एक मानक ORM एपीआई (यानी JPAया JDO) का उपयोग करना चाहते हैं, तो यह स्थायी संस्थाओं के जीवन चक्र राज्यों से निपटने के लिए अपरिहार्य लगता है।
जो मुझे सबसे ज्यादा पसंद JDOहै वह है बिना किसी प्रयास के किसी भी डेटाबेस प्रबंधन प्रणाली के साथ काम करने की क्षमता।
GAE / J को वर्ष के अंत से पहले MYSQL जोड़ने के लिए स्लेट किया गया है।
JPA एक ऐसा तरीका है जिस तरह से यह एक मानकीकृत एपीआई के रूप में धकेल दिया जाता है और हाल ही में EJB3.0 में गति मिली है। JDO भाप को खो दिया है।
न ही!
ऑब्जेक्ट का उपयोग करें, क्योंकि सस्ता है (कम संसाधनों का उपयोग करें) और तेज है। FYI करें: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
ऑब्जेक्ट एक जावा डेटा एक्सेस एपीआई है जो विशेष रूप से Google ऐप इंजन डेटास्टोर के लिए डिज़ाइन किया गया है। यह एक "मध्यम जमीन" पर कब्जा कर लेता है; JDO या JPA की तुलना में उपयोग करने में आसान और अधिक पारदर्शी, लेकिन निम्न-स्तरीय API की तुलना में अधिक सुविधाजनक है। ऑब्जेक्ट को तुरंत उत्पादक बनाने के लिए डिज़ाइन किया गया है, फिर भी जीएई डेटास्टोर की पूरी शक्ति को उजागर करता है।
ऑब्जेक्ट आपको अपनी टाइप की गई वस्तुओं को बनाए रखने, हटाने, हटाने और क्वेरी करने की अनुमति देता है।
@Entity
class Car {
@Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);