2010-07-14 21 views
15

मैं यह पता लगाने की कोशिश कर रहा हूं कि जब आप इसका उपयोग कर रहे हैं तो .NET सेवा संदर्भ क्लाइंट को बंद करने के लिए यह आवश्यक है या नहीं। नेट पर आने वाले लगभग सभी उदाहरण ऐसा प्रतीत नहीं होते हैं, लेकिन उत्पन्न होने वाला क्लाइंट IDISposable लागू करता है और चूंकि यह किसी सेवा से कनेक्शन खोलता है, तो मेरा अंतर्ज्ञान मुझे बताता है कि आपको उस कनेक्शन को बंद करने की आवश्यकता है जब आप इसके साथ किया जाता है।क्या मुझे इसका उपयोग करते समय .NET सेवा संदर्भ क्लाइंट को बंद करने की आवश्यकता है

private void button1_Click(System.Object sender, System.EventArgs e) 
{ 
    ServiceReference1.Service1Client client = new 
     ServiceReference1.Service1Client(); 
    string returnString; 

    returnString = client.GetData(textBox1.Text); 
    label1.Text = returnString; 
} 

मुझे लगता है कि होता है कि आप कम से कम इस विधि के अंत में client.Close() बुलाना चाहिए, और बेहतर अभी तक में पहली पंक्ति लपेट:

यहाँ एक कोड नमूना मैं http://msdn.microsoft.com/en-us/library/bb386386(v=VS.90).aspx से खींचा है एक प्रयोग कथन। मैं यह जानने के लिए बस सर्वोत्तम प्रतिक्रियाएं प्राप्त करने के लिए कुछ प्रतिक्रिया प्राप्त करना चाहता था।

उत्तर

20

हाँ, आप करते हैं, लेकिन ऐसा करने पर आपको बहुत सावधान रहने की आवश्यकता है। ICommunicationObject लागू करने वाली किसी भी चीज को बंद करते समय, वस्तु पर निपटने का संभावित कारण होता है कि इस घटना में अत्यधिक मात्रा में समय लगेगा कि चैनल पर कोई त्रुटि या गलती है।

इस वजह से

, यह निर्धारित है कि आप Close method फोन और फिर IDisposable पर Dispose विधि कॉल, कुछ अपवाद प्रकार के लिए कैच का एक नंबर का उपयोग कर और बुला Abort इससे पहले कि आप अंत में Dispose कहते हैं।

आप इस तर्क को IDisposable कार्यान्वयन में लपेट सकते हैं जिसका उपयोग आप using कथन में कर सकते हैं, क्योंकि मेरे पास outlined in a blog post on this matter है।

कुंजी यहाँ एक टोकन है कि कार्यान्वयन में IDisposable लागू करता है और फिर बनाने के लिए, फोन Close, प्रासंगिक अपवादों को पकड़ने, Abort फोन (यदि आवश्यक हो) और फिर फोन Dispose है।

इसे एक विस्तार विधि के रूप में कार्यान्वित किया गया है जो IDisposable पर लौटाता है जो बदले में आपको इसे using कथन में उपयोग करने की अनुमति देता है।

4

सबसे अच्छा अभ्यास है, अगर वर्ग IDisposable को लागू करता है, एक finally खंड में Dispose() कॉल करें, या साथ using() { }

संपादित
लपेट @casperOne टिप्पणी नीचे के बाद यह WCF ग्राहकों लगती अधिक व्यवहार किया जाना चाहिए सावधानी से। मुझे यह नहीं पता था, और इसका उपयोग करके थोड़ा परेशान है,() ने मुझे अब तक अच्छी तरह से सेवा दी है।

+1

मैं उलझन में हूं कि मुझे मिली सभी एमएसडीएन उदाहरण ऐसा क्यों नहीं करते हैं। क्या वे उनके द्वारा दिए गए उदाहरणों में सर्वोत्तम प्रथाओं को चित्रित नहीं करना चाहते हैं? – Criss

+0

आपको उम्मीद है, लेकिन मुझे लगता है कि नमूने आम तौर पर अन्य वर्गों के बारे में विशिष्ट बिंदुओं का प्रदर्शन कर रहे हैं। मैंने क्रिप्टो नमूनों को देखा है जो फ़ाइल को एन्कोड करते हैं जो फ़ाइलस्ट्रीम उदाहरणों के आसपास भी कोशिश नहीं करते हैं, और हम कभी ऐसा नहीं करेंगे, क्या हम? (!) –

+1

-1: आईसीओएमयूनेशन ऑब्जेक्ट को लागू करने वाली चीजें केवल उन पर बुलाए जाने वाले कारणों से निपटने की अनुमति नहीं दे सकती हैं: http://caspershouse.com/post/Using-IDisposable-on-WCF-Proxies-(or-any- ICommunicationObject- कार्यान्वयन) .aspx और यहां: http://msdn.microsoft.com/en-us/library/aa355056.aspx - आपको कुछ अपवादों के सामने छोड़ना होगा और * फिर * निपटान करें। – casperOne

-2

सबसे अच्छी बात यह है कि Dispose() के लिए जेनरेट किए गए क्लाइंट कोड को देखें और देखें कि यह वास्तव में कुछ भी है, जैसे कि HTTP कनेक्शन या कुछ।

एक तरफ, यह सिर्फ हो सकता है कि इंटरफेस यह IDisposable से विरासत में मिली लागू करता है क्योंकि कुछ ग्राहक हो सकता है, कुछ के निपटान के लिए भले ही है कि विशेष रूप से एक नहीं है की जरूरत है। यह MemoryStream जैसा है, एक वर्ग जो IDisposable लागू करता है क्योंकि सभी Stream एस करते हैं, लेकिन यह वास्तव में किसी भी अप्रबंधित संसाधनों से निपटता नहीं है।

दूसरी ओर, using का उपयोग करने के लिए कभी भी दर्द होता है, भले ही Dispose() एक खाली विधि है। और एमएस उदाहरण वास्तव में वास्तव में खराबusing का उपयोग न करने के बारे में भी हैं, भले ही उन्हें (उदा। here), इसलिए उनके उदाहरण को अच्छे सबूत के रूप में न लें जिन्हें आपको आवश्यकता नहीं है।

+0

मैं व्यक्तिगत रूप से रिवर्स इंजीनियर को तृतीय पक्ष असेंबली नहीं देखता हूं यह देखने के लिए कि क्या मैं निपटान नहीं कर सकता हूं - क्या इससे जोखिम नहीं आते हैं, घटक या ढांचे के अगले संस्करण को आते हैं, आपको * आवश्यकता है * निपटाने के लिए और एक कोडेबेस के साथ छोड़ दिया गया है जो जीसी को अप्रबंधित संसाधन सफाई छोड़ देता है? –

+1

-1: कार्यान्वयन के खिलाफ कोडिंग और अनुबंध द्वारा नहीं * हमेशा * एक बुरा विचार है। यदि प्रकार IDISposable लागू करता है, तो निपटान * हमेशा * कहा जाना चाहिए। ऐसा करने का एकमात्र कारण यह नहीं है कि यह निर्धारित किया गया है कि आपके पास एक विशेष मामला है और यह ऐसा करने में आपके सिस्टम को नुकसान पहुंचा रहा है और कामकाज की आवश्यकता है। इसके अलावा, मेमोरीस्ट्रीम के आपके उदाहरण में, आपको * निपटान करना चाहिए, क्योंकि यह गारंटी नहीं है कि भविष्य में अप्रबंधित स्मृति का उपयोग बैकिंग स्टोर के रूप में नहीं किया जाएगा, इसलिए यदि आपका पहलू बदल गया है तो आपका कोड भविष्य का सबूत नहीं होगा । – casperOne

+0

@neil, फिर हर तरह से निपटान कॉल(); मैंने सुझाव दिया क्योंकि आपके पास वास्तविक कोड है। @casperOne, इंटरफ़ेस को कोडिंग अक्सर एक अच्छा विचार है, लेकिन एक लचीला नियम के रूप में, यह इस तथ्य को खो देता है कि सिस्टम सही नहीं हैं। अप्रबंधित स्मृति टुकड़ा, उदाहरण के लिए, लाल हेरिंग है: मैं अप्रबंधित स्मृति का उपयोग करने के लिए IList को कार्यान्वित कर सकता हूं, लेकिन अगर उपभोक्ता कोड आईएलआईएस इंटरफ़ेस को कोड करता है, तो वह यह भी नहीं जान पाएगा कि वह निपटान() को कॉल कर सकता है। –

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

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