एक नए प्रोजेक्ट के लिए जेपीए हमेशा रिलेशनल डेटा से निपटने के लिए अनुशंसित उपकरण है या क्या ऐसे परिदृश्य हैं जहां स्प्रिंग जेडडीबीएमप्लेट एक बेहतर विकल्प है? आपकी प्रतिक्रिया में विचार करने के लिए कुछ कारक:
जवाबों:
यदि आप एक डोमेन मॉडल के माध्यम से अपने डेटाबेस स्कीमा का उपयोग नहीं करना चाहते हैं तो स्प्रिंग JdbcTemplate का उपयोग करें। JdbcTemplate का उपयोग करके आप अधिक लचीलापन के साथ निचले स्तर की पहुंच का उपयोग कर रहे हैं, लेकिन शायद अधिक बॉयलरप्लेट भी।
स्प्रिंग JdbcTemplate को आसानी से विदेशी डेटाबेस स्कीमा और एक संग्रहीत कार्यविधि फ़ोकस के साथ उपयोग किया जा सकता है। JPA का उपयोग करके आपको यह सुनिश्चित करने की आवश्यकता है कि डेटाबेस स्कीमा डोमेन मॉडल में सही ढंग से मैप करता है।
दोनों प्रौद्योगिकियों को रिलेशनल डेटाबेस, एसक्यूएल और लेनदेन जानने वाले डेवलपर्स की आवश्यकता होती है। JPA के साथ आपको अधिक छिपी हुई जटिलता मिलती है।
JPA मेरे ज्ञान को अधिक आसानी से डेटा कैशिंग लेयर्स के लिए प्लग-इन करने योग्य है, क्योंकि ऑब्जेक्ट ओरिएंटेड फोकस कैश एंट्री आइडेंटिफिकेशन, अपडेट और अमान्यकरण को आसान बनाता है।
आप JdbcTemplate आधारित बैकएंड को बेहतर तरीके से ट्यून कर सकते हैं, लेकिन ज्यादातर मामलों में अधिक कोड शामिल होते हैं।
विचार करने के लिए कुछ अन्य पहलू यह है कि यद्यपि जेपीए के साथ आपको अपने डेटाबेस स्कीमा के लिए एक डोमेन मॉडल मिलता है, आपको अक्सर अतिरिक्त डीटीओ कक्षाओं का उपयोग करने की आवश्यकता होगी। JdbcTemplate का उपयोग करके आप सीधे डीटीओ कक्षाओं के साथ काम कर सकते हैं।
मुझे इस पोस्ट के लिए थोड़ी देर हो गई है, लेकिन मैं ORM पर JdbcTemplate का उपयोग करने के लिए हूं। मैं जानता हूँ कि एसक्यूएल (बहुत अच्छी तरह से) और वास्तव में मेरे डीबी से "अमूर्त" होना नहीं चाहता है। मुझे सबसे अधिक समय लगता है, मेरे ऐप डीबी विचारों का उपयोग कर रहे हैं जहां मैं सबसे अधिक व्यापार तर्क को धक्का देता हूं। मैंने JDbcTemplate कार्यान्वयन वाले DAO को ठीक से स्तरित किया है। ऐसा लगता है कि "साफ" और सबसे बॉयलरप्लेट कोड JdbcTemplate द्वारा छिपा हुआ है (और यह ऑनलाइन प्रलेखन है तो बेहतर है कि ORM सामान लगता है)। सीमित समय के लिए मैंने हाइबरनेट जैसे कुछ का उपयोग किया है, मैंने पाया जब यह काम करता है, तो यह मुझे कुछ समय बचाता है ... लेकिन जब यह ठीक से काम नहीं कर रहा था, तो मुझे "डब्ल्यूटीएफ" डिबगिंग के दिनों की लागत आई। मुझे कभी भी अधिक खर्च नहीं करना पड़ा है तो 20 मिनट JdbcTemplate DAO को डिबग करना है। मुझे लगता है कि कुंजी, जैसा कि अन्य ने नोट किया है, आप SQL / स्कीमा डिज़ाइन के साथ कितने सहज हैं
मैं @Timo से सहमत हूं। केवल अन्य जानकारी जो मैं जोड़ता / बढ़ाता हूं, वह यह है कि ORM के पास आपके डेटा के लिए शुद्ध sql एक्सेस से अलग शब्दार्थ हैं।
ORM की बात इस तथ्य को दूर करने के लिए है कि आपका डेटा किसी DB में है, जितना संभव हो। जब आप ओआरएम का ठीक से उपयोग करते हैं, तो सभी दृढ़ता ऑपरेशन एक (उम्मीद) पतली परत से निपटा जाता है। आपके मॉडल ऑब्जेक्ट में कोई दृढ़ता कोड नहीं होगा; तथ्य यह है कि आप ORM का उपयोग कर रहे हैं अपने मॉडल के लिए अदृश्य होना चाहिए।
इस वजह से, ORM आपके जीवन को कुछ विशेष प्रकार के ऑपरेशनों के लिए आसान बनाता है, अर्थात् सरल CRUD ऑपरेशन। आप अपने मॉडल ऑब्जेक्ट को लोड कर सकते हैं, उन्हें प्रस्तुत कर सकते हैं, उन्हें अपडेट कर सकते हैं, उन्हें आसानी से हटा सकते हैं। यह आपके जीवन को आसान बनाता है क्योंकि जब आप अपने डेटा तक पहुंचते हैं, तो आपको मॉडल ऑब्जेक्ट वापस मिल जाते हैं, जिस पर आप व्यावसायिक तर्क लिख सकते हैं। यदि आप JDBC का उपयोग करते हैं, तो आपको डेटा से अपनी वस्तु उदाहरणों को 'हाइड्रेट' करना होगा, जो जटिल और त्रुटि-प्रवण हो सकता है।
ORM हमेशा सबसे अच्छा विकल्प नहीं है। जेपीए एक नौकरी के लिए एक उपकरण है, यदि उपकरण उस नौकरी के लिए पर्याप्त नहीं है जिसे आप एक बेहतर उपकरण खोजना चाहते हैं। उदाहरण के लिए, मेरे पास एक ऐसा परिदृश्य था जहाँ मुझे पूरी वस्तु ग्राफ को कॉपी करना था और उन वस्तुओं की एक नई प्रति बचानी थी। अगर मैंने ORM का उपयोग किया था (जैसे मैंने करने की कोशिश की), मुझे सभी वस्तुओं को DB से लोड करना था, फिर उन्हें कॉपी करें, फिर नई वस्तुओं को सहेजें। मैंने बहुत लंबा रास्ता तय किया।
बेहतर समाधान बस jdbc आधारित संचालन का उपयोग करना और नई पंक्तियों को बनाने के लिए 'सेलेक्ट थ्रू एसक्यूएल कॉल' डालना था। यह तेज था, कोड सरल था।
दूसरी बात यह है कि आप JDBC के साथ सहज हैं, और समय सीमा है, आपको ORM बैंडवागन पर कूदने की ज़रूरत नहीं है। स्प्रिंग JdbcTemplate कक्षाएं अत्यंत शक्तिशाली और सहायक हैं। कभी-कभी नौकरी के लिए सबसे अच्छा उपकरण वह होता है जिसे आप जानते हैं। आपको ओआरएम के साथ खुद को परिचित करना चाहिए, लेकिन उच्च उम्मीदों वाले प्रोजेक्ट के लिए जरूरी नहीं है। सीखने के लिए बहुत कुछ है और इसकी तुच्छता नहीं है - वास्तव में आप jdbc बनाम orm का उपयोग करने के विकल्प में जटिलताओं के एक सेट का व्यापार कर रहे हैं।
अन्य उत्तरों में इसका उल्लेख नहीं है लेकिन दोनों का उपयोग करना ठीक है। अपने ऐप में मैं JPA और JdbcTemplate का उपयोग करता हूं, crud प्रकार के संचालन के लिए मैं JPA का उपयोग करता हूं, लेकिन रिपोर्टिंग के लिए या जहां यह आसान है मैं jdbcTemplate का उपयोग करता हूं।
@Repository
public class FooRepository
{
@PersistenceContext
private EntityManager entityManager;
@Autowired(required = true)
private JdbcTemplate jdbcTemplate;
public void saveFoo(Foo foo)
{
this.entityManager.persist(foo);
}
public List<SomeReportPojo> getSomeReport()
{
return this.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
स्प्रिंग के बारे में बड़ी बात यह है कि जेपीए अपवादों से स्प्रिंग दाओ अपवाद के पदानुक्रम के अपवाद का अनुवाद जेपीए और jdbcTemplate दोनों के साथ काम करता है। तो JPA का उपयोग करें जब यह समझ में आता है और जब यह समझ में आता है तो jdbcTemplate।
getSomeReport()होना चाहिए ? this.jdbcTemplate. ...this.entityManager. ...
काम पर हम हाइबरनेट JDBCTemplate का उपयोग करते हैं क्योंकि इसमें अधिक लचीलापन है। इसका JPA से बेहतर प्रदर्शन भी है क्योंकि आप अपने ऐप में बहुत सारे अनावश्यक डेटा को "लोड" नहीं कर रहे हैं।
JDBCTemplate मामले में, आपका एसक्यूएल कौशल आपको सही गति पर वही प्रदान करने में एक लंबा रास्ता तय करता है, जिसकी आपको आवश्यकता है।