क्या मुझे डेटासेट और डेटाटेबल को निपटाना चाहिए?


197

डेटासेट और डेटाटेबल दोनों ही आईडीसोपायरी को लागू करते हैं, इसलिए, पारंपरिक सर्वोत्तम प्रथाओं द्वारा, मुझे उनके डिस्पोज़ () तरीकों को कॉल करना चाहिए।

हालाँकि, मैंने अब तक जो भी पढ़ा है, डेटासेट और डेटाटेबल में वास्तव में कोई अप्रबंधित संसाधन नहीं हैं, इसलिए डिस्पोज़ () वास्तव में बहुत कुछ नहीं करता है।

इसके अलावा, मैं सिर्फ using(DataSet myDataSet...)इसलिए उपयोग नहीं कर सकता क्योंकि डेटासेट में डेटाटेबल्स का एक संग्रह है।

इसलिए, सुरक्षित होने के लिए, मुझे myDataSet.Tables के माध्यम से पुनरावृत्त करना होगा, प्रत्येक डेटाटेबल्स का निपटान, फिर डेटासेट का निपटान।

तो, क्या मेरे सभी डेटासेट और डेटाटेबल्स पर डिस्पोज़ () कॉल करने के लिए यह परेशानी के लायक है?

परिशिष्ट:

आप में से जो लोग सोचते हैं कि डेटासेट का निपटान किया जाना चाहिए: सामान्य तौर पर, डिस्पोज़ करने के लिए पैटर्न का उपयोग करना है usingया try..finally, क्योंकि आप गारंटी देना चाहते हैं कि डिस्पोज़ () कहा जाएगा।

हालांकि, यह एक संग्रह के लिए बदसूरत वास्तविक उपवास करता है। उदाहरण के लिए, एक अपवाद को फेंकने () में से एक को कॉल करने पर आप क्या करते हैं? क्या आप इसे निगलते हैं (जो "बुरा" है) ताकि आप अगले तत्व को निपटाने के लिए जारी रख सकें?

या, क्या आप सुझाव देते हैं कि मैं सिर्फ myDataSet.Dispose () कहता हूं, और myDataSet.Tables में DataTables को निपटाने के बारे में भूल जाता हूं?


9
डिस्पोज़ को किसी अपवाद को फेंकना नहीं है। अगर ऐसा होता है — तो यह अच्छी तरह से नहीं लिखा गया है, इसलिए ... {कुछ कोशिश करें।) (); } catch {} पर्याप्त होना चाहिए। - blogs.msdn.com/b/clyon/archive/2004/09/23/233464.aspx
ल्यूकस्वा

3
मैंने अपने एक ऐप में एक स्पष्ट मेमोरी लीक देखा, जो बहुत सारे डेटासेट ऑब्जेक्ट का उपयोग करता है। मैं कॉल नहीं कर रहा था। उन वस्तुओं के लिए "ब्लॉक" का उपयोग कर (या) का उपयोग करें। तो, मैं कोड के माध्यम से चला गया और हर जगह पर एक "प्रयोग" ब्लॉक को जोड़ा जो मैं एक डेटासेट या एक डेटाटेबल बना रहा था, और वॉइला मेमोरी अब जारी की गई है। मुझे एक ठोस संकेत लगता है जो .Dispose (), वास्तव में, DataSet और DataTable के लिए आवश्यक है।
चक्कर .stackoverflow

जवाबों:


147

यहाँ कुछ चर्चाएँ बताई जा रही हैं कि डेटासेट के लिए डिस्पोज़ क्यों आवश्यक नहीं है।

निपटाने के लिए या नहीं देने के लिए? :

डेटासेट में डिस्पोज़ विधि केवल विरासत के साइड इफेक्ट के कारण मौजूद है - दूसरे शब्दों में, यह वास्तव में अंतिम रूप देने में उपयोगी कुछ भी नहीं करता है।

क्या डिसेप्ट को डेटाटेबल और डेटासेट ऑब्जेक्ट पर बुलाया जाना चाहिए? MVP से कुछ स्पष्टीकरण शामिल हैं:

System.data नाम स्थान (ADONET) में अप्रबंधित संसाधन नहीं हैं। इसलिए जब तक आपने खुद को इसमें कुछ खास नहीं जोड़ लिया है, तब तक उनमें से किसी को निपटाने की कोई जरूरत नहीं है।

निपटान विधि और डेटासेट को समझना? स्कॉट एलन से प्राधिकरण के एक टिप्पणी के साथ है:

प्रैटिस में हम शायद ही किसी डेटासेट को डिस्पोज़ करते हैं क्योंकि यह बहुत कम लाभ प्रदान करता है "

इसलिए, आम सहमति यह है कि वर्तमान में किसी डेटासेट पर Dispose को कॉल करने का कोई अच्छा कारण नहीं है।


7
प्रदान किए गए लिंक पूरी तरह से इस बिंदु से चूक गए कि डेटाटेबल एक प्रकार की अंतिम वस्तु है। कृपया नीचे नरीमन का उत्तर देखें।
हरमन

दिलचस्प जवाब लेकिन SqlConnection, SqlCommand और SqlDataAdapter के बारे में क्या, इस विवाद को स्पष्ट रूप से कहा जाना चाहिए?
विली

@ मुझे लगता है कि बहुत से लोग IDisposables के लिए एक कथन का उपयोग करते हैं। का उपयोग कर (SqlConnection cn = new SqlConnection (connectionString)) {का उपयोग करना (SqlCommand cm = new SqlCommand (commandString, cn)) {cn.Open (); cm.ExecuteNonQuery (); }}
DOK

1
@Willy हाँ उन लोगों को पूरी तरह से निपटाया जाना चाहिए क्योंकि वे अप्रबंधित संसाधनों का उपयोग करते हैं। यह स्पष्ट रूप से कहा जाता है या एक usingब्लॉक का उपयोग करना आप पर निर्भर है।
डी स्टैनले

129

अपडेट (1 दिसंबर, 2009):

मैं इस उत्तर में संशोधन करना चाहता हूं और माना कि मूल उत्तर त्रुटिपूर्ण था।

मूल विश्लेषण उन वस्तुओं पर लागू होता है जिन्हें अंतिम रूप देने की आवश्यकता होती है - और यह बिंदु कि प्रथाओं को एक सटीक, बिना गहराई के समझ के सतह पर स्वीकार नहीं किया जाना चाहिए।

हालांकि, यह पता चला है कि DataSets, DataViews, DataTables उनके निर्माणकर्ताओं में अंतिम रूप से दबा देते हैं - यही कारण है कि कॉलिंग डिस्पोज () उन पर स्पष्ट रूप से कुछ भी नहीं करता है।

संभवतः, ऐसा इसलिए होता है क्योंकि उनके पास अप्रबंधित संसाधन नहीं होते हैं; इस तथ्य के बावजूद कि MarshalByValueComponent मानव रहित संसाधनों के लिए भत्ते बनाता है, इन विशेष कार्यान्वयनों की आवश्यकता नहीं है और इसलिए इसे अंतिम रूप देना पड़ सकता है।

(उस .NET लेखकों को अंतिम रूप से अंतिम प्रकार के लिए इस अभ्यास के महत्व को सामान्य रूप से सबसे अधिक स्मृति पर कब्जा करने वाले बहुत प्रकार पर कब्जा करने के लिए ध्यान रखना चाहिए।)

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

बहुत पढ़ने के बाद, यहाँ मेरी समझ है:

यदि किसी ऑब्जेक्ट को अंतिम रूप देने की आवश्यकता होती है, तो यह मेमोरी को लंबे समय तक कब्जे में ले सकता है - यहाँ की आवश्यकता क्यों है: ए) कोई भी प्रकार जो एक विध्वंसक को परिभाषित करता है (या एक प्रकार से विरासत में मिला है जो विनाशकारी को परिभाषित करता है) को अंतिम रूप दिया जाता है; ख) आवंटन पर (निर्माता के चलने से पहले), एक सूचक को अंतिम रूप देने वाली कतार पर रखा गया है; ग) एक अंतिम रूप देने वाली वस्तु को सामान्य रूप से 2 संग्रह की आवश्यकता होती है (मानक 1 के बजाय); घ) अंतिम रूप देना दमन को अंतिम रूप देने वाली कतार से कोई वस्तु नहीं हटाता (जैसा कि एसओएस में अंतिम रूप से बताया गया है) यह आदेश भ्रामक है; यह जानना कि वस्तुओं को अंतिम रूप देना कतार में है (और अपने आप में) सहायक नहीं है; यह जानते हुए कि कौन सी वस्तुएं अंतिम रूप से कतार में हैं और अभी भी अंतिम रूप देने में मदद मिलेगी (क्या इसके लिए कोई कमांड है?)

दमन को अंतिम रूप देना ऑब्जेक्ट के हेडर में रनटाइम को इंगित करता है कि उसे अपने अंतिम रूप को लागू करने की आवश्यकता नहीं है (FReachable कतार को स्थानांतरित करने की आवश्यकता नहीं है); यह अंतिम रूप से कतार पर रहता है (और एसओएस में अंतिम रूप से सूचित किया जाता है)

DataTable, DataSet, DataView कक्षाएं सभी MarshalByValueComponent में निहित हैं, एक अंतिम वस्तु जो अप्रबंधित संसाधनों को संभाल सकती है (संभवतः)

  • क्योंकि DataTable, DataSet, DataView अप्रबंधित संसाधनों को प्रस्तुत नहीं करते हैं, वे अपने निर्माणकर्ताओं में अंतिम रूप देते हैं
  • हालांकि यह एक असामान्य पैटर्न है, यह कॉल करने वाले को उपयोग के बाद Dispose पर कॉल करने की चिंता से मुक्त करता है
  • यह और तथ्य यह है कि DataTables संभावित रूप से अलग-अलग DataSets में साझा किए जा सकते हैं, संभवतः इसीलिए DataSets, DataTables को निपटाने की परवाह नहीं करता है
  • इसका मतलब यह भी है कि ये वस्तुएं एसओएस में अंतिम रूप से दिखाई देंगी
  • हालांकि, इन वस्तुओं को अभी भी एकल संग्रह के बाद पुनः प्राप्त किया जाना चाहिए, जैसे कि उनके गैर-अंतिम योग्य समकक्षों की तरह

4 (नए संदर्भ):

मूल उत्तर:

इस पर बहुत सारे भ्रामक और आम तौर पर बहुत खराब उत्तर हैं - जो कोई भी यहां उतरा है उसे शोर को अनदेखा करना चाहिए और नीचे दिए गए संदर्भों को ध्यान से पढ़ना चाहिए।

बिना किसी संदेह के, निपटान को किसी भी अंतिम वस्तु पर बुलाया जाना चाहिए

DataTables हैं Finalizable।

कॉलिंग डिस्पोज मेमोरी की रीक्लेमिंग को काफी तेज कर देता है।

MarshalByValueComponent कॉल GC.SuppressFinalize (यह) अपने निपटान में () - इस लंघन का मतलब है कि स्मृति के पुनःप्राप्त होने से पहले सैकड़ों Gen0 संग्रह नहीं तो दर्जनों का इंतजार करना होगा:

अंतिम रूप देने की इस बुनियादी समझ के साथ हम पहले से ही कुछ बहुत महत्वपूर्ण चीजों को घटा सकते हैं:

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

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

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

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

संदर्भ:

1 - http://msdn.microsoft.com/en-us/library/ms973837.aspx

2 - http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry http://www.dotnetfunda.com/articles/article524-net-best-practice-no-2-improve-garbage -collector प्रदर्शन का उपयोग-finalizedispose-pattern.aspx

3 - http://codeidol.com/csharp/net-framework/Inside-the-CLR/Automatic-Memory-Management/


अच्छी बात। जब आप कई डेटाटेबल्स के साथ डेटासेट रखते हैं तो आप आमतौर पर अपने कोड को कैसे बनाते हैं? बयानों का उपयोग करते हुए नेस्टेड के टन? एक ही कोशिश..बस एक बार में इसे साफ करने के लिए?
मबेकिश

14
बयान "हालांकि, यह पता चला है कि DataSets, DataViews, DataTables अपने कंस्ट्रक्टर्स में अंतिम रूप से दबा देते हैं - यही कारण है कि उन पर डिपोज () कॉलिंग स्पष्ट रूप से कुछ भी नहीं करता है।" एक गैर-अनुक्रमिक है: दो अवधारणाएं काफी हद तक असंबंधित हैं; अंतिम रूप से दबाने वाली कोई चीज़ अभी भी Dispose () में कुछ कर सकती है। वास्तव में, यह वास्तव में अधिक समझ में आता है अगर हम इसे उल्टा करते हैं: डिस्पोज़ () कुछ भी नहीं करता है, यही कारण है कि यह कंस्ट्रक्टर में अंतिमकरण को दबा देता है, अर्थात क्योंकि ऐसा करने के लिए कुछ भी नहीं होगा यह अंतिम रूप से कॉल करने के साथ जीसी को परेशान नहीं करना चाहता है ( जिसे आमतौर पर डिस्पोज कहते हैं)।
मार्क Gravell

धन्यवाद। क्या यह चर्चा लागू होती है TableAdapter?
बॉन्डोलिन


24

आपको यह मान लेना चाहिए कि यह कुछ उपयोगी है और वर्तमान में कुछ नहीं होने पर भी निपटान को कॉल करें। नेट फ्रेमवर्क अवतारों, इस बात की कोई गारंटी नहीं है कि यह भविष्य के संस्करणों में इस तरह से रहेगा जो अक्षम संसाधन उपयोग के लिए अग्रणी होगा।


इस बात की कोई गारंटी नहीं है कि यह भविष्य में या तो आईडियाजॉल को लागू करेगा। मैं आपसे सहमत होता अगर यह प्रयोग (...) के रूप में सरल था, लेकिन डेटासेट के मामले में, यह कुछ भी नहीं के लिए बहुत परेशानी की तरह लगता है।
मबेकिश

28
यह मानने के लिए काफी सुरक्षित है कि यह हमेशा आईडीसिसोपयोगी लागू करेगा। इंटरफ़ेस जोड़ना या निकालना एक ब्रेकिंग परिवर्तन है, जबकि डिस्पोज़ का कार्यान्वयन बदलना नहीं है।
ग्रेग डीन

5
इसके अलावा, एक अलग प्रदाता के पास एक कार्यान्वयन हो सकता है जो वास्तव में आईडीसिसोप्लिमेंट के साथ कुछ करता है।
मैट स्प्रेडली

यह उल्लेख नहीं है कि DataTableसील नहीं किया गया है - जब आप कर रहे हैं तो कोई बड़ी बात नहीं है new DataTable, लेकिन जब DataTableतर्क के रूप में या विधि कॉल के परिणामस्वरूप काफी महत्वपूर्ण होता है ।
लुआण

17

यहां तक ​​कि अगर ऑब्जेक्ट में कोई मानव रहित संसाधन नहीं है, तो ऑब्जेक्ट ग्राफ़ को तोड़कर GC मदद कर सकता है। सामान्य तौर पर, यदि ऑब्जेक्ट आईडीआईसपोजेबल लागू करता है तो डिस्पोज़ () को बुलाया जाना चाहिए।

डिस्पोज़ () वास्तव में कुछ करता है या नहीं, दिए गए वर्ग पर निर्भर करता है। DataSet के मामले में, निपटान () कार्यान्वयन MarshalByValueComponent से विरासत में मिला है। यह कंटेनर से खुद को हटा देता है और डिस्पोजल इवेंट को कॉल करता है। स्रोत कोड नीचे है (.NET रिफ्लेक्टर के साथ असंतुष्ट):

protected virtual void Dispose(bool disposing)
{
    if (disposing)
    {
        lock (this)
        {
            if ((this.site != null) && (this.site.Container != null))
            {
                this.site.Container.Remove(this);
            }
            if (this.events != null)
            {
                EventHandler handler = (EventHandler) this.events[EventDisposed];
                if (handler != null)
                {
                    handler(this, EventArgs.Empty);
                }
            }
        }
    }
}

1
वास्तव में। मैंने हाल ही में कुछ कोड देखे हैं जहाँ बहुत सारे डेटाटेबल्स एक बहुत बड़े लूप में बनाए गए थे बिना डिसपोज़ किए। इससे कंप्यूटर पर सभी मेमोरी का उपभोग किया जा रहा है और मेमोरी से बाहर निकलते ही प्रक्रिया क्रैश हो जाती है। के बाद मैंने कहा कि डेवलपर को DataTable पर निपटान कॉल करने के लिए समस्या चली गई।
रिचर्डॉड

7

क्या आप स्वयं डेटाटेबल्स बनाते हैं? क्योंकि किसी भी ऑब्जेक्ट (जैसा कि DataSet.Tables में) के बच्चों के माध्यम से पुनरावृत्ति करना आमतौर पर आवश्यक नहीं है, क्योंकि यह माता-पिता का काम है कि वे सभी बच्चे के सदस्यों को निपटाने के लिए।

आम तौर पर, नियम यह है: यदि आपने इसे बनाया है और यह आईडीआईसोपेरिकल लागू करता है, तो इसका निपटान करें। यदि आपने इसे नहीं बनाया है, तो इसका निपटान न करें, यह मूल वस्तु का काम है। लेकिन प्रत्येक ऑब्जेक्ट में विशेष नियम हो सकते हैं, दस्तावेज़ीकरण की जांच करें।

.Net 3.5 के लिए, यह स्पष्ट रूप से कहता है "अब और उपयोग न करने पर इसे डिस्पोज़ करें", इसलिए मैं यही करूँगा।


4
जो मैं समझता हूं, उससे आम सहमति यह है कि एक वस्तु को अपने स्वयं के अप्रबंधित संसाधनों का निपटान करना चाहिए। हालाँकि, प्रत्येक व्यक्ति को
हटाने के

1
सच है, संग्रह हमेशा कुछ ऐसा होता है जिसे मैं विशेष मानता हूं क्योंकि वे आमतौर पर "कुछ भी" नहीं कर रहे हैं, वे महज ... कंटेनर हैं, इसलिए मैंने इसके बारे में कभी परेशान नहीं किया।
माइकल Stum

7

मैं किसी भी समय किसी वस्तु को डिस्पोज़ करने योग्य कहता हूं। यह एक कारण के लिए है।

डेटासेट विशाल मेमोरी हॉग हो सकते हैं। जितनी जल्दी उन्हें साफ-सफाई के लिए चिह्नित किया जा सके, उतना ही बेहतर होगा।

अपडेट करें

इस प्रश्न का उत्तर देते हुए मुझे 5 साल हो गए हैं। मैं अब भी अपने जवाब से सहमत हूं। यदि कोई निपटान विधि है, तो इसे तब बुलाया जाना चाहिए जब आप ऑब्जेक्ट के साथ किया जाता है। IDispose इंटरफ़ेस एक कारण के लिए लागू किया गया था।


5
कॉलिंग डिस्पोज़ मेमोरी को पुनः प्राप्त करने में तेजी नहीं लाता है, ऐसा करने के लिए आपको मैन्युअल रूप से कचरा कलेक्टर शुरू करना होगा जो आमतौर पर एक बुरी योजना है।
टेट्रानट्रोट्रॉन

2
यदि डिस्पोज़ शून्य के संदर्भों का एक समूह सेट करता है, तो यह वस्तुओं को संग्रह के लिए उम्मीदवार बना सकता है जो अन्यथा छोड़ दिया जा सकता है।
ग्रेग डीन

1
डिस्पोज़ की बात प्रबंधित वस्तुओं की मेमोरी को साफ़ नहीं करना है - यह कचरा कलेक्टर का काम है। मुद्दा अप्रबंधित वस्तुओं को साफ करना है। ऐसा प्रतीत होता है कि डेटासेट के पास कोई अप्रबंधित संदर्भ नहीं है, इसलिए सैद्धांतिक रूप से उन्हें बुलाया जाने की आवश्यकता नहीं है। यह कहा जा रहा है, मैं कभी भी ऐसी स्थिति में नहीं रहा हूँ जहाँ मुझे अपने तरीके से बाहर जाना पड़ा हो डिस्पोजल - मैं इसे वैसे भी कॉल करूंगा।
cbp

4
प्राथमिक IDisposable के उपयोग अप्रबंधित संसाधन जारी करने के लिए है। अक्सर बार यह राज्य को एक तरीके से संशोधित भी करता है जो एक निपटाए गए उदाहरण के लिए समझ में आता है। (अर्थात गुण मिथ्या पर सेट हैं, संदर्भ शून्य पर सेट हैं, आदि)
ग्रेग डीन

3
यदि किसी वस्तु पर एक निपटान विधि है, तो इसे बिना किसी कारण के लिए वहां रखा गया है, भले ही यह अप्रबंधित वस्तुओं की सफाई के लिए है या नहीं।
चक कॉनवे

4

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

मैं वास्तव में कामना करता हूं कि एसओ ने लोगों को वोटिंग के लिए मजबूर किया कि वे वास्तव में जवाब लिखने से पहले टिप्पणी लिखें।


+ 1 मुझे लगता है कि कुछ लोग दूसरों को विभिन्न दृष्टिकोणों पर विचार करने की अनुमति नहीं देना चाहते हैं।
DOK

2
नीचे मतदान, किसी भी तरह से लोगों को अलग-अलग दृष्टिकोणों पर विचार करने से रोकता है।
ग्रेग डीन

1

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


6
यह अब हो सकता है, जो जानता है कि यह बाद में क्या करेगा।
ग्रेग डीन

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

0

साफ़ () फ़ंक्शन का उपयोग करने का प्रयास करें। यह निपटाने के लिए मेरे लिए बहुत अच्छा काम करता है।

DataTable dt = GetDataSchema();
//populate dt, do whatever...
dt.Clear();

0

डेटा डिस्प्यूट करने की आवश्यकता नहीं है (क्योंकि डेटासेट ने मार्शलबायवेल्यूकम्पोनेंट इनहेरिट किया है और मार्शलबायल्यूकंपोनेंट ने आईडिसपॉलेट इंटरफ़ेस लागू किया है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.