लिंक से SQL डेटाकॉन्टेक्स्ट के एकाधिक/एकल उदाहरण

Question

मेरे पास एक प्रोजेक्ट है जिसमें टेबल के एक सामान्य सेट में डेटा पूछने और संशोधित करने के लिए कई अलग-अलग वर्ग हैं। मैंने एक .dbml फ़ाइल सेट की है जो हमें डेटा कॉन्टेक्स्ट क्लास प्रदान करती है। मेरा सवाल यह है कि डेटाकॉन्टेक्स्ट का एक उदाहरण सभी ऑब्जेक्ट्स द्वारा उपयोग किया जाना चाहिए, या क्या कई उदाहरण उपयोग करने के लिए सुरक्षित हैं। मैं एक डेटाकॉन्टेक्स्ट के मामले में थ्रेड सुरक्षा के बारे में भी सोच रहा हूं, और इसके तरीकों तक पहुंच सिंक्रनाइज़ की जानी चाहिए।

Answer 1

रिक स्ट्राल आपके विकल्पों के बारे में एक अच्छा लेख है: http://www.west-wind.com/weblog/posts/246222.aspx।

यह भी देखें: LINQ to SQL - where does your DataContext live?।

आप तैनाती के प्रत्येक प्रकार के लिए एक अलग रणनीति चाहते हो सकता है - वेब, डेस्कटॉप, खिड़कियां सेवा ...

संक्षेप, आपके विकल्प हैं:

• वैश्विक DataContext - में खतरनाक बहु लड़ी वातावरण (वेब ​​ऐप्स सहित)। याद रखें कि इंस्टेंस सदस्यों को थ्रेड-सुरक्षित होने की गारंटी नहीं है (ब्रैडली ग्रिंगर के answer से ऊपर)।
• प्रति थ्रेड डेटाकॉन्टेक्स्ट - जटिल। यदि आपका डेटा कॉन्टेक्स्ट परिवर्तनों को ट्रैक कर रहा है तो आपको उचित समय पर उन्हें फ़्लश करना सुनिश्चित करना होगा। DataContext को इंस्टेंट करना, संग्रह करना और पुनर्प्राप्त करना एक दर्द है।
• डाटाकॉन्टेक्स्ट प्रति परमाणु क्रिया - आप परिवर्तनों को ट्रैक करने की क्षमता खो देते हैं क्योंकि एक डेटाकॉन्टेक्स्ट ऑब्जेक्ट बनाता है जबकि अन्य अपडेट या इसे हटा देता है। एक डेटा ऑब्जेक्ट को एक नए डेटाकॉन्टेक्स्ट में संलग्न करना आपके जैसा काम नहीं कर सकता है।
• डाटाकॉन्टेक्स्ट प्रति डेटा ऑब्जेक्ट - यह सुरुचिपूर्ण लगता है क्योंकि आपको तत्काल (डेटा बनाने और संलग्न करने) पर डेटाकॉन्टेक्स्ट के साथ झगड़ा करना है और अपडेट/हटाएं (डेटा ऑब्जेक्ट को खींचें और इसका उपयोग करें)।

मैंने प्रति डेटा ऑब्जेक्ट डेटाकॉन्टेक्स्ट का चयन किया। यह प्रशंसक समाधान नहीं हो सकता है लेकिन यह सभी तैनाती वातावरण में काम करता है।

Answer 2

मैंने हमेशा सुना है कि आपको डेटाकॉन्टेक्स्ट के एक उदाहरण का उपयोग करना चाहिए। मैं आमतौर पर अपने व्यापार तर्क वर्ग में अपने डीसी का सिंगलटन उदाहरण बना देता हूं, और अपने सभी linq प्रश्नों के लिए इसका उपयोग करता हूं।

मुझे यकीन है कि यहां पर कुछ लिनक्स गुरु आपको सटीक कारण दे सकते हैं कि आपको केवल अपने डेटा संदर्भ वर्ग के उदाहरण क्यों होना चाहिए ... मैं बिल्कुल निश्चित नहीं हूं।

Answer 3

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

यही कारण है कि मैं अपने प्रत्येक वर्ग के लिए डेटा-संदर्भ ऑब्जेक्ट का उपयोग करता हूं - मेरा User वर्ग का अपना डेटा-संदर्भ है, मेरा Application वर्ग का अपना स्वयं का है, और आगे।

यह पैटर्न मेरी परियोजनाओं में रोल-बैक करने की अधिकांश परेशानियों को समाप्त करता है।

Answer 4

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

Answer 5

मैं प्रत्येक लेनदेन के लिए डेटाकॉन्टेक्स्ट का एक नया उदाहरण उपयोग करता हूं।

पुरानी घटनाओं का पुन: उपयोग करना परेशानी हो सकती है, और डेटाकॉन्टेक्स्ट की सामग्री को फटकार देगी, क्योंकि किसी भी आइटम को लोड किया गया है, आपको ट्रैक करना होगा - आपका ऐप धीमा और धीमा हो जाएगा, स्मृति को सूख जाएगा।

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