क्या एकाधिक डेटा कॉन्टेक्स्ट कक्षाएं कभी उपयुक्त हैं?

Question

एएसपीनेट 3.5 एप्लिकेशन में लिंक्टोस्क्ल का पूरी तरह से उपयोग करने के लिए, DataContextclasses (जिसे आम तौर पर वीएस 2008 में डिजाइनर का उपयोग करके किया जाता है) बनाना आवश्यक है। यूआई परिप्रेक्ष्य से, डेटाकॉन्टेक्स्ट आपके डेटाबेस के उन अनुभागों का एक डिज़ाइन है जिसे आप LinqToSQL के माध्यम से बेनकाब करना चाहते हैं और LinqToSql की ORM सुविधाओं को स्थापित करने में अभिन्न अंग हैं।

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

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

एकाधिक डेटाकॉन्टेक्स (डीबी नेमस्पेस से संबंधित) पर एक विचार या अनुभव किसी भी बड़े डेटाकॉन्टेक्स्ट क्लास (पूरे डीबी के अनुरूप) के स्थान पर (या इसके अतिरिक्त) के स्थान पर उचित है या नहीं?

Answer 1

मैं जॉन के जवाब से असहमत हूं। डेटाकॉन्टेक्स्ट (या लिंक टू एंटिटी ऑब्जेक्ट कॉन्टेक्स्ट) एक कनेक्शन की तुलना में "काम की इकाई" से अधिक है। यह परिवर्तन ट्रैकिंग आदि का प्रबंधन करता है।विवरण के लिए इस ब्लॉग पोस्ट देखें:

Lifetime of a LINQ to SQL DataContext

इस ब्लॉग पोस्ट के चार मुख्य बिंदुओं कि DataContext हैं:

1. आदर्श रूप से एक "काम की इकाई" के लिए अनुकूल है दृष्टिकोण
2. भी "स्टेटलेस" सर्वर आपरेशन
3. के लिए लांग रहता उपयोग
नहीं बनाया गया है के लिए डिज़ाइन किया गया है

4. Should be used very carefully after 
   any SumbitChanges() operation. 
   

यह देखते हुए कि, मैं एक से अधिक DataContext का उपयोग कर वास्तव में किसी भी harm- करना होगा, काम के विभिन्न प्रकार के लिए अलग DataContexts बनाने अपने LinqToSql impelmentation अधिक usuable और संगठित बनाने में मदद मिलेगी नहीं लगता। केवल नकारात्मक पक्ष यह है कि आप अपने डीएमबीएल को स्वतः उत्पन्न करने के लिए SQLमीटर का उपयोग नहीं कर पाएंगे।

Answer 2

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

Answer 3

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

Answer 4

मुझे लगता है कि जॉन सही है।

आपको लगता है कि कैसे का समर्थन करते हैं "मेरी मुख्य चिंता है कि instantiating और एक विशाल DataContext वर्ग अलग-अलग कार्य है कि डाटाबेस के विशिष्ट क्षेत्रों से संबंधित के लिए हर समय निपटाने आवेदन संसाधनों पर एक अनावश्यक लगाने थोपना होगा कि" बयान? आपका प्रयोग क्या है जो दिखाता है कि एक बड़ा डेटाकॉन्टेक्स्ट एक प्रदर्शन बाधा है? एकाधिक डेटाकॉन्टेक्स होने के कारण कई डेटाबेस होने की तरह बहुत कुछ है और समान परिदृश्यों में समझ में आता है, जो कि शायद ही कभी है। यदि आप एकाधिक डेटाकॉन्टेक्स के साथ काम कर रहे हैं तो आपको ट्रैक रखने की आवश्यकता है कि कौन सी ऑब्जेक्ट्स डेटाकॉन्टेक्स्ट से संबंधित हैं और आप उन ऑब्जेक्ट्स से संबंधित नहीं हो सकते हैं जो समान डेटा संदर्भ में नहीं हैं। यह कोई वास्तविक लाभ के लिए एक महंगा डिजाइन गंध है।

@Evan "डेटाकॉन्टेक्स्ट (या लिंक टू एंटिटी ऑब्जेक्ट कॉन्टेक्स्ट) एक कनेक्शन की तुलना में" काम की इकाई "से अधिक है" यही कारण है कि आपके पास एक से अधिक डेटाकॉन्टेक्स्ट नहीं होना चाहिए। आप एक समय में एक "काम की इकाई" क्यों चाहते हैं?

Answer 5

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

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

अब ये महत्वपूर्ण कमीएं हैं। क्या उन पर काबू पाने के लिए पर्याप्त फायदे हैं?

मेरा मुख्य चिंता का विषय है कि instantiating और एक विशाल DataContext वर्ग सभी अलग-अलग कार्य है कि संबंधित डाटाबेस के विशिष्ट क्षेत्रों के लिए आवेदन संसाधनों पर एक अनावश्यक लगाने थोपना होगा के लिए समय निपटाने: सवाल प्रदर्शन का उल्लेख है।

असल में, यह सच नहीं है कि एक बड़ी डीसी काम की एक विशिष्ट इकाई में तत्काल या उपयोग करने के लिए काफी अधिक समय लेती है। वास्तव में, after the first instance is created in a running process, subsequent copies of the same DC can be created almost instantaneously।

पूरी तरह से विदेशी कुंजी संबंधों के साथ एक एकल, बड़े डेटाबेस के लिए एकाधिक डीसी से एकमात्र वास्तविक लाभ यह है कि आप अपने कोड को थोड़ा बेहतर बना सकते हैं। लेकिन आप आंशिक कक्षाओं के साथ पहले से ही ऐसा कर सकते हैं।

इसके अलावा, कार्य अवधारणा की इकाई मूल प्रश्न के लिए वास्तव में प्रासंगिक नहीं है। काम की यूनिट आम ​​तौर पर, कितना एक काम एक भी डीसी उदाहरण कर रही है को संदर्भित करता है नहीं कितना काम एक डीसी वर्गसक्षम करने का है।