2009-11-27 3 views
22

मैं आमतौर पर इस तरह कोड का उपयोग करें:एसक्यूएलकॉमैंड है। (एस) को एसक्यूएलकनेक्शन से निपटने के लिए आवश्यक है?

using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConn"].ConnectionString)) 
{ 
    var command = connection.CreateCommand(); 
    command.CommandText = "..."; 
    connection.Open(); 
    command.ExecuteNonQuery(); 
} 

मेरी command स्वचालित रूप से निपटाया जाएगा? या नहीं और मुझे इसे using ब्लॉक में लपेटना है? क्या इसे SqlCommand का निपटान करने की आवश्यकता है?

+0

यह बहुत बुरा है माइक्रोसॉफ्ट ने एसक्यूएल कॉमांड को एक घटक बनाया है। अगर उन्हें वास्तव में डिजाइनर समर्थन के लिए एक घटक की आवश्यकता होती है, तो यह एक हल्के SqlCommand पर एक रैपर हो सकता था जो IDISposable लागू नहीं करता है। –

उत्तर

22

बस इस कार्य करें:

using(var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConn"].ConnectionString)) 
using(var command = connection.CreateCommand()) 
{ 
    command.CommandText = "..."; 
    connection.Open(); 
    command.ExecuteNonQuery(); 
} 

कॉल नहीं आदेश पर निपटाने के लिए कुछ भी बहुत बुरा काम नहीं चलेगा। हालांकि इसे निपटाना supress the call to the finalizer पर कॉल करना होगा, जिससे कॉलिंग प्रदर्शन में वृद्धि का निपटान करेगी।

+11

"कमांड पर निपटान नहीं करना कुछ भी बुरा नहीं करेगा।" सच है, लेकिन इसका उपयोग न करें; यह केवल 'SqlCommand' के लिए सच है। दूसरी ओर, 'SqlCeCommand' का निपटारा नहीं, उदाहरण के लिए, * आपके मोबाइल डिवाइस को स्मृति से बाहर निकलने का कारण बन जाएगा। (बस वहां गया, ऐसा किया गया ...) – Heinzi

+2

'निपटान' कन्स्ट्रक्टर ऐसा करने के बाद अंतिमकरण को दबा नहीं देता है। –

8

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

आपके द्वारा दिए गए उदाहरण में, आप कमांड के लिए ब्लॉक का उपयोग करके अतिरिक्त आंतरिक जोड़ सकते हैं, साथ ही साथ कनेक्शन के लिए बाहरी उपयोग को बनाए रख सकते हैं।

+2

हां, सबसे सुरक्षित नीति हमेशा डिस्पोजेबल वस्तुओं का निपटान करना है - विशेष रूप से यदि आपने * इसे * बनाया है! उदाहरण के लिए एक अच्छा तरीका नहीं है जो एक धारा को स्वीकार करता है, और उस विधि के अंदर धारा का निपटान करता है। एक और चेतावनी यह है कि आप हमेशा उपयोगिता कथन के माध्यम से निर्दोषता के साथ निपटान नहीं कर सकते हैं। डब्ल्यूसीएफ प्रॉक्सी एकमात्र व्यावहारिक उदाहरण है जिसे मैं जानता हूं। अगर रिमोट एंड पर कुछ गलत हो जाता है और आपको अपवाद मिलता है तो चैनल बंद हो जाता है और निपटान करता है तो मूल अपवाद को बदलकर, एक नया अपवाद फेंकता है, जो एक गंभीर समस्या हो सकती है। –

+1

डब्ल्यूसीएफ का उपयोग न करने का एक और कारण! टिप ऑफ के लिए धन्यवाद ;-) –

1

आप Reflector का उपयोग करके इस तरह की चीजें पा सकते हैं।

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

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

4

हां, आपको यह भी करना चाहिए कि कार्यान्वयन वर्तमान में बहुत कुछ नहीं कर रहा है, आपको नहीं पता कि भविष्य में इसे कैसे बदला जा रहा है (उदाहरण के लिए नए फ्रेमवर्क संस्करण)। आम तौर पर, आपको सुरक्षित वस्तुओं पर होने के लिए IDisposable लागू करने वाली सभी वस्तुओं का निपटान करना चाहिए।

हालांकि, अगर आपरेशन टाल रहा है और आप (जब asynchroneously काम कर रहा है, या जब एक SqlDataReader या तो लौटने उदाहरण के लिए) संपूर्ण संभावना को नियंत्रित नहीं करते हैं, तो आप CommandBehaviorCloseConnection के लिए इतना है कि जैसे ही सेट कर सकते हैं पाठक के रूप में किया जाता है, कनेक्शन आपके लिए ठीक से बंद/निपटाया जाता है।

2

अभ्यास में, आप Dispose छोड़ सकते हैं। यह किसी भी संसाधन को मुक्त नहीं करता है। कन्स्ट्रक्टर ऐसा करता है क्योंकि यह अंतिमकरण को भी दबाने नहीं देता है।

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

संबंधित मुद्दे