मेरे पास कार्यकर्ता भूमिका है जो हर सेकेंड डेटाबेस के साथ कुछ काम करती है।एंटिटी फ्रेमवर्क का डीबीकॉन्टेक्स्ट लाइफटाइम वर्कर रोल
क्या कार्यकर्ता शुरू होने पर कार्यकर्ता शुरू होने और इसे पूरे जीवनकाल में उपयोग करने के लिए DbContext प्रारंभ करना ठीक है?
डीबी कनेक्शन कैसे संभाला जाता है? क्या होगा अगर डेटाबेस ऑफ़लाइन हो और वापस ऑनलाइन हो? क्या मैं अभी भी संदर्भ का उपयोग कर पाऊंगा?
मेरी सलाह है कि प्रत्येक ऑपरेशन के लिए संदर्भ बनाना, उपयोग और नष्ट करना ... उस पर लटकाओ। मैं पहली बार चिंता करता था क्योंकि मुझे नहीं पता था कि डीबीकॉन्टेक्स्ट बनाने के लिए कितना महंगा था, जवाब बहुत नहीं है।
आप एक DbContext उदाहरण आप भी (बहुत जल्दी) समस्याओं में चलेंगे यह आंतरिक स्थिति मॉडल है कि लोड हो जाने पर पहले से
मैं इस उत्तर को स्वीकार करता हूं क्योंकि यह सही है लेकिन मेरे उत्तर में विस्तारित स्पष्टीकरण भी देखें। – daramasala
यह आलेख ऑनस्टार्ट() में डीबीकॉन्टेक्स्ट सेट करने और रन() के अंदर उपयोग करने का सुझाव देता है: https://azure.microsoft.com/en-gb/documentation/articles/cloud-services-dotnet-get-started/#create-the -आवेदन-से खरोंच। यह कहना सही नहीं है कि केवल सही है लेकिन केवल FYI –
वह आलेख जो मैं देख सकता हूं उससे एज़ूर क्लाउड स्टोरेज से निपट रहा है, स्थानीय डिस्क पर एंटीटी फ्रेमवर्क नहीं। नेटवर्क संचार से निपटने वाली कुछ प्रणालियों पर * यह * कनेक्शन शुरू करने और इसे खोलने के लिए बेहतर हो सकता है, लेकिन यह हैंडशेक की मात्रा पर निर्भर करता है जिसे करने की आवश्यकता है (यानी HTTP उस तरह से काम नहीं करता है)। इसलिए मुझे लगता है कि आपको अवधारणाओं को मिश्रण न करने के लिए सावधान रहना होगा क्योंकि रीढ़ की हड्डी (और इसलिए ऑपरेशन) दोनों के बीच जंगली रूप से अलग होगी। चीयर्स, पॉल –
वस्तु के संस्करणों (अद्यतन जो कुछ भी) के लिए संघर्ष की रिपोर्टिंग शुरू कर देंगे के रूप में पुन: उपयोग रखने के लिए प्रयास करते हैं मेरे सर्वोत्तम वर्तमान ज्ञान के लिए, मुख्य DbContext अमूर्त कार्य की इकाई है।
डीबीकॉन्टेक्स्ट जब भी इसकी आवश्यकता हो (यानी context.SaveChanges() पर) डीबी कनेक्शन खोलता है और बंद करता है तो डीबी कनेक्शन संदर्भ के दायरे से अप्रासंगिक है।
इस तरह से देखकर, अब मुझे लगता है कि यह तय करने के लिए कि DbContext उदाहरण का दायरा क्या होना चाहिए, आपको अपने काम की इकाई और इकाइयों को स्मृति में प्रबंधित करने की आवश्यकता है।
उदाहरण के लिए, यह मेरे सवाल है, आमतौर पर यह कार्यकर्ता की जीवन भर एक भी संदर्भ उदाहरण का उपयोग करते हुए कोई मतलब नहीं होगा क्योंकि:
आमतौर पर आप प्रत्येक भूमिका मंगलाचरण में विभिन्न संस्थाओं पर काम करेंगे। इस मामले में, संदर्भ को इन इकाइयों को स्मृति में वैसे भी लोड करने की आवश्यकता होगी।
ओवरटाइम, संदर्भ स्मृति में अधिक से अधिक इकाइयों का प्रबंधन करेगा जो प्रदर्शन समस्याओं का कारण बनेंगे (क्योंकि यह ग्राफ को परिवर्तनों और चीजों को देखने के लिए स्कैन करता है) और आखिरकार स्मृति समस्याएं होती हैं।
लंबे समय तक स्मृति में इकाइयों को रखने से संदर्भ में इकाइयों और डीबी में वास्तविक डेटा के बीच असंगतता की संभावना बढ़ जाती है। इन असंगतताओं को हल करने में प्रदर्शन में लागत हो सकती है।
संक्षेप में, यह शायद कार्यकर्ता भूमिका की जीवन भर एक ही DbContext उदाहरण उपयोग करने के लिए गलत है।
DbContext के दायरे पर निर्णय लेने के लिए आप जिस काम को कार्यान्वित कर रहे हैं उसकी शर्तों के संदर्भ में सोचें।
बहुत व्यापक, बहुत अस्पष्ट। पहले स्थान पर दो प्रश्न हैं। फिर, पहला कार्यकर्ता भूमिका में आप जो करते हैं उस पर निर्भर करता है, कितने समय तक, कितने डेटा पर। दूसरे प्रश्न के लिए आपको एंटिटी फ्रेमवर्क के साथ कनेक्शन लचीलापन देखना चाहिए। –
@GertArnold प्रश्न एक कार्यकर्ता भूमिका में एकल 'डीबीकॉन्टेक्स्ट' उदाहरण का उपयोग करने के बारे में है। अन्य प्रश्न वे चीजें हैं जिन्हें मैं इस संबंध में चिंतित हूं। "कार्यकर्ता के पूरे जीवनकाल में कितनी देर तक" - "। इसका मतलब है वीएम स्टार्टअप से वीएम शटडाउन, नहीं? "कनेक्शन लचीलापन" - क्या आप कह रहे हैं कि कनेक्शन हानि एक क्षणिक विफलता है और इसे पुनः प्रयास तर्क से निपटाया जाएगा? – daramasala