स्प्रिंग बनाम ईजेबी। क्या स्प्रिंग EJB की जगह ले सकता है? [बन्द है]


96

चूंकि स्प्रिंग EJB की तरह ही लेनदेन का उपयोग करने में सक्षम है । मेरे लिए, स्प्रिंग EJB का उपयोग करने की आवश्यकता को बदलने में सक्षम है। क्या कोई मुझे बता सकता है कि ईजेबी का उपयोग करने के अतिरिक्त फायदे क्या हैं?

जवाबों:


201

वसंत अपनी शुरुआत से ही EJB के विकल्प के रूप में विकसित किया गया था, इसलिए इसका उत्तर यह है कि आप EJB के स्थान पर Spring का उपयोग कर सकते हैं।

यदि EJBs का उपयोग करने के लिए "लाभ" है, तो मैं कहूंगा कि यह आपकी टीम के कौशल पर निर्भर करेगा। यदि आपके पास कोई स्प्रिंग विशेषज्ञता नहीं है, और बहुत सारे ईजेबी अनुभव हैं, तो शायद ईजेबी 3.0 के साथ चिपके रहना एक अच्छा कदम है।

EJB मानक का समर्थन करने के लिए लिखे गए ऐप सर्वर, सिद्धांत रूप में, एक आज्ञाकारी जावा EE ऐप सर्वर से दूसरे में पोर्ट किए जा सकते हैं। लेकिन इसका मतलब है कि किसी भी और सभी विक्रेता-विशिष्ट एक्सटेंशन से दूर रहना जो आपको एक विक्रेता में बंद कर देता है।

ऐप सर्वर (जैसे, वेबलॉग, टॉमकैट, जेओएसओएस आदि) के बीच आसानी से स्प्रिंग पोर्ट क्योंकि यह उन पर निर्भर नहीं करता है।

हालाँकि, आप स्प्रिंग में बंद हैं।

वसंत अच्छा OO डिजाइन प्रथाओं (जैसे, इंटरफेस, परतें, चिंताओं को अलग करना) को प्रोत्साहित करता है जो किसी भी समस्या को छूने में लाभान्वित करते हैं, भले ही आप Guice या किसी अन्य DI ढांचे पर स्विच करने का निर्णय लें।

अद्यतन: यह सवाल और जवाब 2014 में पांच साल पुराना है। यह कहने की जरूरत है कि प्रोग्रामिंग और अनुप्रयोग विकास की दुनिया ने उस समय में बहुत कुछ बदल दिया है।

यह अब केवल जावा या सी #, स्प्रिंग या ईजेबी के बीच चयन नहीं है। Vert.x के साथ जावा ईई को पूरी तरह से बचाना संभव है। आप ऐप सर्वर के बिना अत्यधिक स्केलेबल, पॉलीग्लॉट एप्लिकेशन लिख सकते हैं।

अपडेट: इट्स मार्च 2016। स्प्रिंग बूट जावा ईई ऐप सर्वर के बिना एप्लिकेशन लिखने का एक बेहतर तरीका प्रदान करता है। आप एक निष्पादन योग्य JAR बना सकते हैं और इसे JVM पर चला सकते हैं।

मुझे आश्चर्य है कि अगर ओरेकल जावा ईई कल्पना का समर्थन करना जारी रखेगा। ईजेबी के लिए वेब सेवाओं ने कार्यभार संभाल लिया है। EJB समाधान मृत है। (एकदम मेरे विचार।)


7
मेरी राय में, "लॉक इन" स्प्रिंग का वर्णन करने के लिए एक वाक्यांश बहुत मजबूत है। आखिरकार, स्प्रिंग को एक साथ सब कुछ गोंद करने के लिए डिज़ाइन किया गया है, उन्हें बदलने के लिए नहीं, आप हमेशा वही चुन सकते हैं जिसे आप एकीकृत करना चाहते हैं। इसके अलावा, सब कुछ लॉक-इन है, यहां तक ​​कि सबसे सरल एपाचे कॉमन्स हमें लॉक करते हैं, लेकिन हम अभी भी इसे हर रोज इस्तेमाल कर रहे हैं।
क्रिस्टोफर यांग

3
वीएमवेयर / स्प्रिंग के लिए कोई वैकल्पिक विक्रेता नहीं हैं जिस तरह से आप जावा ईई प्लेटफार्मों के लिए ओरेकल, रेड हैट और आईबीएम के बीच चयन कर सकते हैं। मेरा बस यही मतलब है। यह स्प्रिंग की क्षमता या उपयोगिता पर कोई टिप्पणी नहीं है। मुझे यह बहुत पसंद है। मैं हर दिन इसका इस्तेमाल करता हूं और रात को सोता हूं।
duffymo

1
@ChristopherYang यह सही है। मेरा मतलब है, "जावा" एक विक्रेता लॉक-एन होगा। इसलिए आखिरकार, हमें बहस करने से रोकने और कुछ करने की जरूरत है। :-)
cbmeeks

4
यह सवाल लगभग पांच साल पुराना है। व्यक्तिगत रूप से, मुझे लगता है कि EJBs दिनांकित तकनीक है जो HTTP वेब सेवाओं के लिए हर तरह से खो गई है। सरल और खुली जीत। मुझे REST सेवाएँ दें और आप अपना EJBs रख सकते हैं। वसंत उन्हें अच्छी तरह से समर्थन करता है। यहीं से दुनिया चली गई।
duffymo

1
उत्तर के लिए धन्यवाद। मौजूदा EJB 2.1 एप्लिकेशन से माइग्रेशन के लिए बेहतर एक (SPRING, EJB 3.x) के मूल्यांकन के रूप में लाभों की तलाश में। एक और सवाल, EJB 3.x भी WebService का समर्थन करता है। तो, क्या हम जावा ऐप वितरण और अन्य ऐप्स के लिए WS के लिए JNDI / RMI का लाभ प्राप्त कर सकते हैं?
रईसों

48

पहले, मुझे यह स्पष्ट रूप से कहने दें, मैं यह नहीं कह रहा हूं कि आपको स्प्रिंग का उपयोग नहीं करना चाहिए, लेकिन क्योंकि आप कुछ फायदे पूछ रहे हैं, यहां कम से कम दो विकल्प हैं:

  • EJB 3 एक मानक है जबकि स्प्रिंग नहीं है (यह एक वास्तविक मानक है लेकिन यह एक ही बात नहीं है) और यह भविष्य के भविष्य में नहीं बदलेगा। यद्यपि आप किसी भी एप्लिकेशन सर्वर के साथ स्प्रिंग फ्रेमवर्क का उपयोग कर सकते हैं, स्प्रिंग एप्लिकेशन को स्प्रिंग में ही और विशिष्ट सेवाओं को लॉक करने के लिए चुना जाता है।

  • स्प्रिंग फ्रेमवर्क एप्लिकेशन सर्वर और सेवा पुस्तकालयों के शीर्ष पर बैठता है। सेवा एकीकरण कोड (जैसे डेटा एक्सेस टेम्प्लेट) फ्रेमवर्क में रहता है और एप्लिकेशन डेवलपर्स के संपर्क में है। इसके विपरीत, EJB 3 फ्रेमवर्क को एप्लिकेशन सर्वर में एकीकृत किया जाता है और सर्विस इंटीग्रेशन कोड को एक इंटरफेस के पीछे रखा जाता है। EJB 3 विक्रेता इस प्रकार एप्लिकेशन सर्वर स्तर पर काम करके प्रदर्शन और डेवलपर अनुभव को अनुकूलित कर सकते हैं। उदाहरण के लिए, वे JPA लेनदेन प्रबंधन के साथ JPA इंजन को निकटता से जोड़ सकते हैं। एक अन्य उदाहरण क्लस्टरिंग समर्थन है जो ईजेबी 3 डेवलपर्स के लिए पारदर्शी है।

EJB 3 हालांकि सही नहीं है, लेकिन इसमें अभी भी कुछ फीचर्स (जैसे कि साधारण POJOs जैसे गैर प्रबंधित घटकों के इंजेक्शन) की कमी है।


1
शैक्षिक उत्तर, लेकिन मैं सोच रहा हूं कि आपको नया पीओ शुरू करने के बजाय एक साधारण पीओजेओ को इंजेक्ट करने की आवश्यकता क्यों है?
मर फारुक अल्मालि

4
परीक्षण प्रयोजनों के लिए।
फिलिप

22

पास्कल के अंक मान्य हैं। हालांकि, वसंत के पक्ष में निम्नलिखित हैं।

  • EJB विनिर्देश वास्तव में थोड़ा ढीला है, और इसलिए विभिन्न एप्लिकेशन सर्वरों के साथ अलग-अलग व्यवहार देखे जा सकते हैं। यह ज्यादातर मामलों के लिए सही नहीं होगा, निश्चित रूप से, लेकिन मुझे कुछ "अंधेरे कोनों" के लिए ऐसी समस्या थी।

  • वसंत में बहुत सारे अतिरिक्त उपहार हैं, जैसे वसंत-परीक्षण, एओपी, एमवीसी, जेएसएफ एकीकरण, आदि। ईजेबी में उनमें से कुछ हैं (इंटरसेप्टर, उदाहरण के लिए), लेकिन मेरी राय में वे इतने विकसित नहीं हैं।

अंत में, यह मुख्य रूप से आपके सटीक मामले पर निर्भर करता है।


हो सकता है कि स्प्रिंग की तरह कुछ को केवल एक सर्वलेट इंजन की आवश्यकता होती है जो अधिक सटीक होगा (EJB का उपयोग किसी भी JEE कंटेनर, सर्वलेट इंजन! = JEE कंटेनर) में किया जा सकता है।
पास्कल थिवेंट

1
ठीक है, तकनीकी रूप से, स्प्रिंग को एक सर्वलेट इंजन की भी आवश्यकता नहीं है। उदाहरण के लिए वसंत-परीक्षण एक इन-मेमोरी संदर्भ का उपयोग करता है।
बूझो

3
ठीक है, तकनीकी रूप से, EJBs को न तो स्टैंडअलोन कंटेनर की आवश्यकता होती है और न ही इस तरह से जाने पर। EJB 3.1 के बाद से EJBContainer.createEJBContainer()एक एम्बेडेड कंटेनर का उपयोग करने के लिए मानक एपीआई है। तो, फिर भी, आपका कथन गलत है।
पास्कल थिवेंट

ठीक है, 3.1 काफी नया है और जाहिर है कि मैं इसके बारे में भूल गया था। मेरे जवाब से उस बिंदु को हटा दिया।
Bozho

-30

स्प्रिंग ईजेबी के पूरक के लिए है, इसे प्रतिस्थापित करने के लिए नहीं। स्प्रिंग EJB के ऊपर एक परत है। जैसा कि हम जानते हैं, EJB की कोडिंग एपीआई का उपयोग करके की जाती है, जिसका अर्थ है कि हमें स्प्रिंग फ्रेमवर्क का उपयोग करके एपीआई में सब कुछ लागू करना होगा। हम बॉयलर-प्लेट कोड बना सकते हैं, फिर बस उस प्लेट को ले सकते हैं, उसमें कुछ सामान जोड़ सकते हैं, फिर सब कुछ किया जाता है। आंतरिक रूप से स्प्रिंग ईजेबी के साथ जुड़ा हुआ है - स्प्रिंग ईजेबी के बिना मौजूद नहीं होगा।

स्प्रिंग का उपयोग करने का मुख्य लाभ यह है कि कक्षाओं के बीच कोई युग्मन नहीं है।


8
आप पूरी तरह से गलत हैं, क्षमा करें
जैकब एच

2
माफ़ करना @sasi यह भी एक सही या अच्छे उत्तर के करीब नहीं है .......
प्रकाश

4
"EJB के बिना स्प्रिंग का अस्तित्व नहीं होगा।" यार, क्या तुम असली हो? क्या आपने अपने जीवन में कभी EJB की घोषणा में "@ @Stateless" का उपयोग किया, या इंजेक्शन के लिए \ @EJB एनोटेशन का उपयोग किया? क्या आपको लगता है कि वे जेट्टी या टॉम्कट में काम करेंगे? आपको कैसे लगता है कि लेनदेन वसंत के तहत प्रबंधित किए जाते हैं? आप जानते हैं कि आप एक सर्वलेट कंटेनर में एक स्प्रिंग एप्लिकेशन को सही तरीके से तैनात कर सकते हैं?
99Sono

क्षमा करें, लेकिन आपके पास दोनों की अच्छी तरह से संरचित समझ नहीं है, EJB जावा EE के हिस्से के रूप में और वसंत सम्मेलन-ओवर-कॉन्फ़िगरेशन सिद्धांत के रूप में। वास्तव में यदि आप गहरे में नहीं खोदते हैं तो आप यह सोचकर समाप्त हो सकते हैं कि वे कुछ इसी तरह के हैं या संबंधित हैं या जो कुछ भी है। क्यों? उन दोनों में इंजेक्शन जैसी समानताएं हैं लेकिन उनके बीच का अंतर बहुत बड़ा है। यह सच है कि वसंत का समय ईजेबी की जटिलता के कारण ईजेबी की पीठ के विकल्प के रूप में पैदा हुआ था लेकिन यह था। जावा ईई 5 (ईजेबी 3) के समय के दौरान काफी अच्छा था, जिस तरह से वसंत अपने सीओसी के साथ कर रहा था, उसी तरह से भी कर रहा था
इशिम्वे ऑबैन सांत्वना लेखक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.