2009-03-12 16 views
6

मैं एक डाटाबेस वर्ग जो follwing तरीकों contanins है:सी # स्थिर डेटाबेस कक्षा?

  • सार्वजनिक bool ExecuteUDIQuery (स्ट्रिंग क्वेरी) // UDI = अद्यतन हटाएँ सम्मिलित
  • सार्वजनिक bool ExecuteSelectQuery (स्ट्रिंग क्वेरी)
  • सार्वजनिक bool ExecuteSP (स्ट्रिंग एसपी, स्ट्रिंग [] parms)
  • सार्वजनिक पूर्णांक ExecuteSPReturnValue (स्ट्रिंग एसपी, स्ट्रिंग [] parms)

तरीकों के परिणामों में जमा हो जाती है निजी डेटासेट या डेटाटेबल्स। इन वस्तुओं को गेटर्स के रूप में परिभाषित किया जाता है।

डेटाबेस कक्षा का उपयोग करने वाले लगभग 10 वर्ग हैं। प्रत्येक वर्ग कक्षा डेटाबेस का एक वस्तु बनाता है। अब मैं डाटाबेस क्लास को स्थिर बनाने के बारे में सोच रहा था। यह एक अच्छा विचार है? यदि हां, तो क्यों? नहीं, क्यों नहीं?

उत्तर

5

यदि मैं समझता हूं, डेटाबेस क्लास में कुछ गुण हैं जो क्वेरी के परिणाम संग्रहीत करते हैं? यदि ऐसा है, तो आप उन्हें स्थिर नहीं बना सकते हैं, क्योंकि यह थ्रेड-सुरक्षित नहीं है। यदि इन गुणों में किसी क्वेरी का परिणाम संग्रहीत किया जाता है, तो क्या होगा यदि कोई दूसरी क्वेरी पहले के बाद सही हो जाएगी? यह एक ही स्थिर चर में संग्रहीत किया जाएगा। वेब अनुप्रयोग के लिए भी यही होता है: साइट ब्राउज़ करने वाले किसी अन्य उपयोगकर्ता का परिणाम पहले उपयोगकर्ता के परिणाम बदल देगा।

संपादित करें: सारांशित करने के लिए, जब आप स्थैतिक चर में प्रश्नों का परिणाम संग्रहीत करते हैं, विशेष रूप से कक्षा में उपयोग नहीं किया जाता है, क्योंकि गुण मूल्य आपके सभी आगंतुकों के बीच साझा किया जाएगा, वेबसाइट। यदि 20 आगंतुक एक ही समय में एक प्रश्न करते हैं, तो विज़िटर 1 विज़िटर 20 की क्वेरी के परिणाम देखेंगे।

+0

मैं एक वेबसाइट बना रहा हूँ। तो अगर मैं आपको सही ढंग से समझता हूं, जब 20 आगंतुक कहते हैं और वे सभी एक अलग पृष्ठ का अनुरोध करते हैं (और मेरी डीबी कक्षा स्थैतिक है) यह गलत हो जाती है, है ना? – Martijn

+0

हां, आप सही ढंग से समझते हैं। यदि कक्षा स्थिर है, तो संपत्तियों के आवेदन को साझा किया जाएगा। इसलिए, यदि 20 विज़िटर डेटाबेस क्वेरी करते हैं, तो संपत्ति विज़िटर नंबर 20 द्वारा निष्पादित अंतिम क्वेरी का परिणाम रखेगी। – Razzie

0

यदि आप डीबी के खिलाफ सिर्फ प्रश्न पूछ रहे हैं, तो हाँ इसे स्थिर बनाएं। यदि आपको इस ऑब्जेक्ट को किसी प्रकार की स्थिति रखने की आवश्यकता है तो आपको केवल एक उदाहरण बनाना होगा।

0

यदि आपके पास एक स्थैतिक विधि है तो आपको डेटाबेस खोलने और बंद करने के दौरान उदाहरणों का ट्रैक रखने की आवश्यकता है।

तो आप शायद जो करना चाहते हैं उसके पास उदाहरण या वर्तमान उदाहरण नामक एक स्थिर विधि है। और आपके भीतर स्थिर डीडी-क्लास का एक नया उदाहरण स्थिर विधि में लौट रहा है।

+0

रखते हुए "उदाहरण" में स्रोत कोड की जांच कर सकते खुला एक अच्छा विचार नहीं है। आपको डीबी ASAP से कनेक्शन बंद करना चाहिए। – Inferis

+0

बेशक आपको कनेक्शन बंद करना चाहिए। लेकिन यदि आपके पास आदेशों तक पहुंचने के लिए एक स्थिर वर्ग है तो आप डेटाबेस कनेक्शन को प्रबंधित कर सकते हैं। समाप्त होने के बाद पाठक को बंद करने के लिए एक आदेश है। –

4

आपके विशिष्ट उदाहरण में, मैं कक्षा को स्थिर बनाने के खिलाफ सलाह दूंगा: आप डेटाबेस कक्षा में स्थिति रखते हैं, और कक्षा स्थिर बनाकर, यह राज्य आपके डेटाबेस का उपयोग करके सभी कक्षाओं में साझा किया जाएगा। आपके वर्तमान सेटअप में, प्रत्येक डेटाबेस इंस्टेंस अपना स्वयं का राज्य रखता है, इसलिए डेटाबेस कॉल के साथ एक दूसरे के साथ हस्तक्षेप करने में कोई समस्या नहीं है।

यदि आप विधि कॉल करते समय डेटासेट को वापस करने के लिए डेटाबेस क्लास को दोबारा प्रतिक्रिया देंगे, तो आप इसे स्थिर बना देंगे: डाटाबेस क्लास में कोई भी स्टेटस जानकारी नहीं छोड़ी जाएगी।

लेकिन चूंकि यह मामला नहीं है: नहीं, वर्ग को स्थैतिक मत बनाओ।

+2

मैं इनफेरिस से सहमत हूं। एक मुखौटा वर्ग बनाएं जो डेटाबेस कक्षाओं तक पहुंच को आसान बनाता है एक विकल्प हो सकता है। – Statement

1

यह इस बात पर निर्भर करता है कि आप किस प्रकार का डेटाबेस या ओआरएम उपयोग कर रहे हैं। लेकिन मेरे अनुभव में यह एक अच्छा विचार की तरह लग रहा था लेकिन मुझे shafting समाप्त हो गया। यहां बताया गया है कि LINQ-to-SQL में मेरे लिए यह कैसे किया गया:

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

आप तर्क दे सकते हैं कि स्थैतिक चर मेमोरी में कम पदचिह्न छोड़ते हैं, लेकिन डेटा संदर्भ के लिए पदचिह्न शुरू करने के लिए काफी छोटा है और अंत में कचरा इकट्ठा किया जाएगा।

2

थ्रेड सुरक्षा के बारे में अन्य टिप्पणियों के अलावा पैरालाइलाइजेशन का मुद्दा भी है। आपके मामले में आप एक ही समय में डेटाबेस से कई कनेक्शन खोलने में सक्षम नहीं होंगे और आप कई पैरालेल क्वेरी करने में सक्षम नहीं होंगे, भले ही परिणाम की थ्रेड सुरक्षा कोई समस्या न हो।

इसलिए मैं दूसरों से सहमत हूं, इसमें से एक स्थिर वर्ग न बनाएं।

वर्ग स्थैतिक बनाना सुविधाजनक हो सकता है, लेकिन इसके नए उदाहरण बनाना संभवतः एक महंगी ऑपरेशन नहीं होगा, इसलिए शायद प्रदर्शन-वार हासिल करने के लिए बहुत कुछ नहीं है।

संपादित करें:
मैंने एक टिप्पणी में देखा कि आप अपनी कक्षा का उपयोग किसी वेब साइट पर करना चाहते हैं। उस स्थिति में आपको वास्तव में ऐसा नहीं करना चाहिए। एक स्थिर डेटाबेस वर्ग के साथ आप किसी भी समय सुरक्षित रूप से एक अनुरोध की सेवा कर पाएंगे, और यह वही नहीं है जो आप चाहते हैं।

0

आपकी विधियां स्थिर उपयोग के लिए अच्छी हैं। मुझे लगता है, अब आपको उन्हें स्थैतिक तरीकों में बदलने में कोई परेशानी नहीं है।

लेकिन बाद में आपको लेनदेन का प्रबंधन करने की आवश्यकता होगी। एक वर्ग में लेनदेन प्रबंधन को छोड़कर मुझे लगता है कि बहुत समय बचाता है। और यह परिदृश्य एक गैरस्टिक वर्ग के साथ सबसे अच्छा फिट बैठता है।

1

उत्तर पोस्ट के विपरीत। मैंने एक स्थिर डेटाबेस पहुंच के साथ एक वेबफ्रेमवर्क बनाया है जो यह बहुत अच्छा काम करता है और शानदार प्रदर्शन देता है।

आप http://www.codeplex.com/Cubes