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

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

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

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

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

0
जोड़ा संपादित
विचारों: 2

5 उत्तर

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

0
जोड़ा

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

  1. You lose relationships between some tables. You can try to choose your DC boundaries wisely, but you will eventually run into a situation where it would be very convenient to use a relationship from a table in one DC to a table in another, and you won't be able to.
  2. Some tables may appear in multiple DC's. This means that if you want to add table-specific helper methods, business logic, or other code in partial classes, the types won't be compatible across DC's. You can work around this by inheriting each entity class from its own specific base class, which gets messy. Also, schema changes will have to be duplicated across multiple DC's.

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

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

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

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

साथ ही, कार्य अवधारणा की इकाई मूल प्रश्न के लिए वास्तव में प्रासंगिक नहीं है। काम की इकाई आम तौर पर यह दर्शाती है कि एक डीसी instance कितना काम कर रहा है, डीसी वर्ग </मजबूत> करने के सक्षम है।

0
जोड़ा

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

"मेरी मुख्य चिंता यह है कि डाटाबेस के विशिष्ट क्षेत्रों से संबंधित व्यक्तिगत संचालन के लिए हर समय एक विशाल डेटाकॉन्टेक्स्ट कक्षा को तत्काल और निपटान करना संसाधन संसाधनों पर एक अनावश्यक लगाव लगाया जाएगा"

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

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

0
जोड़ा
हां, ओपी यह मानने में सही नहीं है कि एक बड़े डीसी को तत्काल करने में अधिक समय लगता है। वास्तव में, पहले उदाहरण के बाद चलने वाली प्रक्रिया में बनाया जाता है, उसी डीसी के बाद के उदाहरण लगभग तत्काल बनाए जा सकते हैं।
जोड़ा लेखक Jordan Rieger, स्रोत

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

आजीवन LINQ से SQL डेटा कॉन्टेक्स्ट के लिए

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

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

इस बात को ध्यान में रखते हुए, मुझे नहीं लगता कि एक से अधिक डेटाकॉन्टेक्स्ट का उपयोग करने से कोई नुकसान होगा-वास्तव में, विभिन्न प्रकार के काम के लिए अलग-अलग डेटाकॉन्टेक्स बनाने से आपकी लिंक्टोस्क्ल प्रवेग अधिक उपयोगी और संगठित हो सकेगी। केवल नकारात्मक पक्ष यह है कि आप अपने डीएमबीएल को स्वतः उत्पन्न करने के लिए SQLमीटर का उपयोग नहीं कर पाएंगे।

0
जोड़ा

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

0
जोड़ा