क्या यह एक अच्छा अभ्यास है कि वेब अनुप्रयोग के प्रत्येक प्रमुख अनुभाग के लिए एकाधिक XXX : DbContext कक्षाएं हों (मान लें कि यह डेटाबेस में कम से कम 50 तालिकाओं वाला एक बड़ा है)? उदाहरण के लिए: सदस्यता कॉन्टेक्स्ट, ब्लॉगकॉन्टेक्स्ट, स्टोरकॉन्टेक्स्ट इत्यादि। या सभी डीबी एक्सेस संबंधित सामग्री के लिए एक DatabaseContext रखना अधिक सुविधाजनक है।एकाधिक डीबीकॉन्टेक्स्ट कक्षाएं। अच्छा या बुरा?
एकाधिक डीबीकॉन्टेक्स्ट वर्गों का उपयोग करने से जटिल क्रॉस-लेनदेन का संकेत मिलता है (आप यहां वेब पर इस समस्या का समाधान पा सकते हैं उदाहरण http://pastebin.com/YEDqyH0n) लेकिन इसे उचित ठहराया जा सकता है। यह सब आपके आर्किटेक्चर और अलगाव पर निर्भर करता है जिसे आप डिज़ाइन करना चाहते हैं।
वैसे भी आपको रिपोजिटरी और यूनिटऑफवर्क पैटर्न को देखना चाहिए ताकि आपके डीबीकॉन्टेक्स का उपयोग कैसे किया जा सके। यहां देखें: Multiple DbContexts in N-Tier Application और यहां EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)? यदि आप एएसपी.नेट एमवीसी का उपयोग करते हैं।
50 टेबल के लिए मुझे लगता है कि यह एकाधिक डीबीकॉन्टेक्स के लिए उचित हो सकता है। तो मैं एकाधिक डीबी कॉन्टैक्स का उपयोग करने की सलाह दूंगा। लेकिन आपको अन्य परतों में वास्तविक कार्यान्वयन से स्वतंत्र होने के लिए रिपोजिटरी और यूनिटऑफवर्क पैटर्न का उपयोग करके उन्हें लपेटना चाहिए (इस तरह आप बाद में आसानी से अपना मन बदल सकते हैं और उदाहरण के लिए केवल एक सिग्नल डीबीकॉन्टेक्स्ट का उपयोग कर सकते हैं)।
मुझे उम्मीद है कि इससे मदद मिलती है।
डीबीकॉन्टेक्स्ट पहले से ही रिपोजिटरी और यूनिट-ऑफ-वर्क पैटर्न लागू करता है! –