2012-08-01 9 views
7

मैं कबूल करता हूं, मैं पूरी तरह से grok * हाइबरनेट नहीं करता हूं।हमें अन्य ओआरएम पर nHibernate कब चुनना चाहिए?

चूंकि सूक्ष्म ORMs जैसे Dapper का उपयोग अधिकांश डेटा एक्सेस आवश्यकताओं को हल करने के लिए किया जा सकता है, ऐसे परिदृश्य क्या हैं जिनके लिए बड़ी बंदूक की आवश्यकता होती है जैसे nHibernate? परिस्थितियों के कुछ उदाहरण क्या हैं जहां nHibernate चमक जाएगा? स्पष्ट होने के लिए, मैं "कोड बदलने के बिना अपना डेटाबेस स्विच करने की क्षमता" पर विचार नहीं करता हूं। प्रोग्रामिंग के आठ वर्षों में मुझे वास्तव में ऐसा करने की ज़रूरत नहीं थी, और ऐसा लगता है कि शुरुआत करने के लिए विचार बर्बाद कर रहा है।

मैं किसी भी विचारशील प्रतिक्रिया के लिए खुला रहा हूँ, लेकिन यहाँ हैं सवाल के कुछ उदाहरण मेरे पास है:

  1. जब क्वेरी एपीआई लायक अतिरिक्त काम आप मानचित्रण में डाल दिया है, साफ-सुथरी की तरह कुछ की तुलना में है?
  2. आप आलसी लोडिंग का लाभ कैसे उठा सकते हैं जो विकास प्रयास को सीमित करता है और केवल काम करता है?
  3. बैच बैच कैसे निकालें यह जानने के लिए आपके समय के लायक है?
  4. कैश सिस्टम किस परिदृश्य में बेहतर है, उदाहरण के लिए, पेज आउटपुट कैशिंग? क्या यह गैर-वितरित वातावरण में केवल सच है?
  5. मेरे जैसे एक प्राणघातक को यह समझने की उम्मीद है कि कैसे वितरित वातावरण में nHibernate काम करेगा? मिश्रण कैशिंग, बैचिंग और स्टेटलेस सत्रों पर विचार करें और इस बारे में सोचें कि संतुलित वेब सर्वर कितने भार से निपटेंगे।

उत्तर

6

वाह, बड़ा सवाल। यकीन नहीं है कि केवल एक प्राणघातक इसका जवाब दे सकता है। लेकिन मुझे लगता है कि आप "अपना डेटाबेस स्विच करने की क्षमता" को खारिज करने के लिए बहुत जल्दी हैं। वाणिज्यिक और ओपन सोर्स दोनों में बहुत से सॉफ्टवेयर पैकेज हैं, जो बैकिंग स्टोर के रूप में विभिन्न आरडीबीएमएस के साथ काम करने की क्षमता प्रदान करते हैं। 2+ डेटाबेस प्लेटफार्मों को तैनात करने के लिए एसक्यूएल का प्रबंधन एक पूर्ण दुःस्वप्न बन सकता है, इसलिए किसी चीज को अपने अनुमानित तरीके से बनाएं (कम से कम इसे हाथ से लिखे जाने की तुलना में) एक बड़ा फायदा है। कुछ डेटाबेस प्लेटफार्मों के लिए सिर्फ शैतान के वकील को खेलना, मैं लेन-देन थ्रूपुट में वृद्धि देख सकता था, जिससे डेटाबेस विकल्प को भी महंगा रहने के लिए महंगा लगा। अधिकांश ओआरएम आपको इस तरह से एक या दूसरे तरीके से मदद करेगा - हालांकि एक समृद्ध क्वेरी एपीआई होने पर आपके डेटाबेस की जरूरतों को पर्याप्त जटिल होने पर एक लंबा रास्ता तय हो सकता है।

मुझे लगता है कि संक्षिप्त उत्तर यह है कि जब आपके डेटाबेस को किसी एप्लिकेशन के लिए जटिलता के एक निश्चित स्तर तक पहुंचने की आवश्यकता होती है, तो आपकी आवश्यकता को पूरा करने की लागत निबर्ननेट के सीखने की अवस्था में शामिल लागत से कम हो जाती है। मैं पूरा उत्तर नहीं दे सकता लेकिन आपकी सूची वस्तुओं पर अपने विचार देने की कोशिश करूंगा।

  1. जब आप केवल CRUD से अधिक कर रहे हैं। एकाधिक डेटाबेस प्लेटफार्मों पर जटिल प्रश्नों की आवश्यकता शायद एक अच्छा उदाहरण है। इस प्रकार के ऐप पर आप लगभग दो अलग-अलग कोडबेस बनाए रख सकते हैं (ठीक है, यदि आप संग्रहीत प्रो मार्ग पर जाते हैं तो वे वास्तव में अलग हो जाते हैं) और आपके सभी कोड को .NET में रखने में मूल्य हो सकता है (यह यूनिट करने में सक्षम होना अच्छा है उदाहरण के लिए, अपने शेष कोड के साथ इन प्रश्नों का परीक्षण करें)।
  2. मध्यम ट्रस्ट वातावरण में देखी गई समस्याओं के अलावा, मुझे यकीन नहीं है कि आलसी लोडिंग के बारे में अब "अभी काम नहीं" है। मेरी आंखों में आलसी लोडिंग के साथ एकमात्र समस्या यह है कि आपको बड़ी मात्रा में डेटा लाने के दौरान इसमें आने वाली कुछ समस्याओं से बचने के लिए इसके बारे में पता होना चाहिए, ज्यादातर एन + 1 चुनिंदा समस्या।
  3. आपको बैच स्टेटमेंट्स को समझने की आवश्यकता नहीं है - आपको केवल कॉन्फ़िगरेशन मान सेट करने और इसके बारे में भूलने की आवश्यकता है।यह एक बहुत बड़ा अनुकूलन है कि एनएचबीर्नेट आपके लिए न्यूनतम प्रयास करता है - आपका कोड बहुत साफ हो सकता है जब यह केवल संचालन और लेनदेन नियंत्रण से सीधे संबंधित होता है।
  4. लौटाए गए डेटा को कैश करना फायदेमंद हो सकता है जब आप अलग-अलग उपयोगकर्ताओं के लिए अपने पृष्ठों को अलग-अलग प्रस्तुत कर रहे हैं, या अपनी डोमेन परत में किसी प्रकार की गैर-तुच्छ प्रक्रिया कर रहे हैं। यहां तक ​​कि बुनियादी परिदृश्यों में, पृष्ठ आउटपुट कैशिंग के साथ आप अपने कैश में संपादन पृष्ठ, विवरण पृष्ठ, इत्यादि ... को समाप्त कर सकते हैं, जबकि स्रोत के करीब आपके डेटा को कैशिंग करते हुए आपको केवल एक बार इकाई को कैश करने की आवश्यकता होती है। स्रोत के करीब कैशिंग आपको बालों के डेटा की सेवा से अधिक सुरक्षा भी प्रदान करता है। डेटा-उन्मुख कैश को कई अनुप्रयोगों में या तो सेवाओं के माध्यम से या एनएचबर्ननेट को मेमकैड या रेडिस जैसे आउट-ऑफ-प्रोसेस स्टोर में इंगित करके साझा किया जा सकता है। यह कुछ वातावरण में काफी मूल्यवान हो सकता है।
  5. मुझे यकीन नहीं है कि आपको यह समझने की आवश्यकता है कि यह कैसे काम करता है (कई बार मैं इस तरह की चीज़ के कार्यान्वयन विवरण को समझने की आवश्यकता से खुद को बचाने के लिए ओपन-सोर्स लाइब्रेरी का उपयोग करता हूं)। लेकिन संक्षिप्त जवाब यह है कि उनमें से कोई भी एक वितरित परिदृश्य में कैशिंग के अलावा किसी भी अलग तरीके से व्यवहार नहीं करता है (और केवल दूसरे स्तर पर कैशिंग भी)। जब तक आप एक वितरित कैश प्रदाता का उपयोग करते हैं (या अपने सभी सर्वरों को उसी प्रक्रिया के कैश प्रदाता को इंगित करते हैं) तो आपको उस मोर्चे पर भी अच्छा होना चाहिए।

मैं केवल nHibernate की बात कर रहा हूं, लेकिन मुझे लगता है कि हाइबरनेट के लिए कहानी बहुत समान है। बड़े पैमाने पर, अधिक जटिल अनुप्रयोगों में बहुत लाभ हो सकता है, लेकिन इस लाभ को प्राप्त करने के लिए आपको बहुत सी जटिल जटिलताएं लेने की आवश्यकता है - यह अभी भी सभी समस्याओं के लिए अपने स्वयं के समाधान को चलाने से कम जटिल है * हाइबरनेट आपके लिए हल करता है।

आपके पास ऐसा कैशिंग के आसपास बहुत सारे प्रश्न भी थे। मैं पहले और दूसरे स्तर के कैश कैसे काम करता है इसका विचार पाने के लिए this link पर पढ़ने का सुझाव देता हूं। मैं यहां व्याख्या करने की कोशिश नहीं करूंगा, क्योंकि ऐसा लगता है कि आप पहले से ही लंबे समय तक जवाब में फिट बैठ सकते हैं :)

5

एनएचबर्ननेट बड़ा और शक्तिशाली है लेकिन आपको इसके बारे में सब कुछ पता नहीं है इसका उपयोग सफलता प्राप्त करने के लिए। आपके सवालों के जवाब के लिए:

  1. नेट सूक्ष्म ORMS के सभी किसी भी LINQ समर्थन है कि मैं के बारे में पता है और इसके बजाय अपने कोड में एसक्यूएल तार मिश्रण पर भरोसा नहीं है। LINQ के साथ अपने प्रश्नों का निर्माण करना आपको टाइप-सुरक्षा, संकलन-समय की जांच, और महान रिफैक्टरिबिलिटी प्रदान करता है। यदि सभी प्रश्न SQL स्ट्रिंग का उपयोग कर रहे हैं तो इसमें हजारों प्रश्नों के साथ कोडबेस को दोबारा करने का प्रयास करें ... yikes! और रिफैक्टरिंग करके, मेरा मतलब है कि नए कॉलम, नई टेबल इत्यादि को जोड़ने के रूप में कुछ सरल है जो एंटरप्राइज़ वातावरण में हर समय होता है। रिफैक्टरिंग स्ट्रिंग्स संभव है, हेक लोगों को अभी भी करना है जो संग्रहीत प्रक्रियाओं पर भरोसा करते हैं, लेकिन मुझे यकीन है कि अगर मैं अपने निपटान में टाइप-सुरक्षा करता हूं तो ऐसा करने का फैसला नहीं होगा।

  2. आलसी लोडिंग के साथ, केवल एक चीज जो आपको ध्यान में रखना है वह एक चयन एन + 1 परिदृश्य बना रही है। किसी भी समय जब आप किसी डोमेन ऑब्जेक्ट/इकाई पर फ़ोरैच लूप कर रहे हैं, तो सुनिश्चित करें कि ऑब्जेक्ट (ओं) को पॉप्युलेट करने वाली क्वेरी ने फ़ेच() विधि का उपयोग किया जो आसानी से SQL में जॉइन बनाता है और किसी भी बच्चे ऑब्जेक्ट को पॉप्युलेट करता है। अन्यथा, जब आप ऑब्जेक्ट पर किसी भी बच्चे ऑब्जेक्ट में ऑब्जेक्ट करते हैं और डॉट करते हैं, तो ओआरएम को डेटा लाने के लिए एक और चयन कथन निष्पादित करना होगा। असल में, NHibernate लिंगो में, उत्सुक fetching आपका दोस्त है।

  3. बैचिंग एनएचबेर्नेट के साथ पाई जितनी आसान है। अपने एनएचबीर्नेट कॉन्फ़िगरेशन में, बैचिंग चालू करें और यही वह है। उसके बाद, यदि आपको आवश्यकता हो, तो आप विशेष प्रश्नों के लिए रनटाइम पर बैच आकार समायोजित कर सकते हैं।

  4. मैंने कभी भी दूसरे स्तर पर कैशिंग का उपयोग नहीं किया है।मैं एक बड़े उद्यम वातावरण में काम करता हूं और हमारे ऐप्स कैशिंग के लिए किसी भी आवश्यकता के बिना बहुत तेजी से दौड़ते हैं। NHibernate में पहला स्तर कैश हालांकि कॉन्फ़िगरेशन की आवश्यकता नहीं है और इसे केवल ट्रैकिंग ट्रैकिंग के रूप में सोचा जा सकता है। असल में, आंतरिक रूप से एनएचबेर्नेट एक शब्दकोश रखता है जिसमें से यह ऑब्जेक्ट्स डेटाबेस से पहले से ही पुनर्प्राप्त हो चुका है और डेटाबेस में सहेजे/अपडेट किए जाने के लिए कौन सी ऑब्जेक्ट लंबित हैं। पहला स्तर कैश ऐसा कुछ है जिसे मैं वास्तव में कभी नहीं सोचता लेकिन मुझे लगता है कि यह एक प्राथमिक स्तर पर जानना अच्छा है कि यह कैसे काम करता है।

  5. फिर से, मैं वर्तमान में एक एंटरप्राइज़ वातावरण में काम करता हूं और हमारे पास NHibernate का उपयोग करके सभी प्रकार के अनुप्रयोग हैं; एनएचबीर्नेट को पेश करने वाली सभी शक्तिशाली सुविधाओं का उपयोग करके कुछ सुंदर बुनियादी और अन्य। हालांकि मैंने अपने अनुभव में आमतौर पर जो देखा है, वह यह है कि टीम के हर सदस्य को एनएचबीर्नेट विशेषज्ञ होने की आवश्यकता नहीं है। आम तौर पर 1 - 3 डेवलपर्स बहुत जानकार होंगे और हर कोई इसके बारे में चिंता नहीं करेगा और सिर्फ अपनी संस्थाओं, मैपिंग्स और अपने प्रोग्रामिंग के साथ आगे बढ़ेगा। एक बार आधारभूत संरचना हो जाने के बाद और आपके संगठन ने उन पैटर्नों को हल किया है जो इसे उपयोग करना चाहते हैं, सब कुछ आमतौर पर एक हवा है।

अतिरिक्त विचार:

एक ही स्थान पर कि NHibernate वास्तव में चमकता है पागल डेटाबेस डिजाइन के किसी भी प्रकार है कि आप इसे फेंक मैप करने के लिए की क्षमता है। अब मैं यह नहीं कह रहा हूं कि शुरुआती 9 0 के दशक में कुछ पागल डेटाबेस डिज़ाइन को एक साथ रखा जा सकता है, जहां आपको एक संग्रहीत प्रक्रिया और एक और तालिका में एक साथ शामिल होना है, लेकिन संभव है। मैंने अपने दिन में कुछ पागल मैपिंग किया है। कुछ मैंने सोचा कि असंभव था क्योंकि डेटाबेस को ऐसा करने के लिए डिज़ाइन नहीं किया गया था जिसे हम करना चाहते थे, लेकिन हर बार, दृढ़ता से, मैं अभी भी अच्छे और खराब डेटाबेस डिज़ाइन दोनों को मैप करने में एनएचबीर्नेट की अविश्वसनीय लचीलापन के साथ इसे खींचने का प्रबंधन करता हूं।

माइक्रो-ओआरएमएस के साथ, आप आम तौर पर अपने कोड के साथ एम्बेडेड एसक्यूएल स्ट्रिंग के एक टन के साथ समाप्त होते हैं। यह कैसे साफ और कुशल माना जाता है। ऐसा लगता है कि सभी लोग ऐसा कर रहे हैं जो वे अपने कोड में संग्रहीत प्रक्रियाओं में डाल करने के लिए उपयोग करते हैं। मैं वास्तव में अपनी कुछ परियोजनाओं में माइक्रो-ओआरएम का उपयोग करता हूं, हालांकि यह समझ में आता है, लेकिन आम तौर पर जब मैं केवल कुछ टेबल के लिए एक टेबल पर पूछताछ करता हूं - जटिल जटिल कहां नहीं।

निष्पक्ष होने के लिए, मैं उन लोगों में से एक हूं जिन्होंने एनएचबीरनेट के इंस और आउट सीखने में थोड़ा सा समय निवेश किया है, लेकिन ऐसा इसलिए नहीं क्योंकि मुझे काम के लिए जरूरी था, लेकिन क्योंकि मैं बस चाहता था। मैं काम पर बहुत से लोगों के साथ काम करता हूं जो हर दिन एनएचबीरनेट का उपयोग करते हैं और इसे पूरी तरह से प्राप्त नहीं करते हैं। लेकिन फिर, उन्हें जरूरत नहीं है। आपको बस कुछ बुनियादी चीजों को जानने की जरूरत है और आप जाने के लिए अच्छे हैं।

उम्मीद है कि इससे मदद मिलती है।

संबंधित मुद्दे