कमजोर घटनाओं का उपयोग कब करें?

Question

मैं कमजोर घटनाओं पर एमएसडीएन ट्यूटोरियल को रेफर कर रहा था। मैं मूल बातें समझ गया। मैं एक गैर-डब्ल्यूपीएफ परियोजना पर काम कर रहा हूं और मेरी कक्षा कुछ घटनाओं को उजागर कर रही है। मेरा सवाल यह है कि कमजोर घटनाएं पूरी तरह पुरानी घटना पैटर्न को प्रतिस्थापित करती है? क्या घटनाओं को उजागर करने वाले हर वर्ग का उपयोग करना अच्छा होता है? कमजोर घटनाओं का उदारतापूर्वक उपयोग करने के दुष्प्रभाव क्या हैं?

Answer 1

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

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

कुछ परिदृश्यों स्वाभाविक कमजोर घटना पैटर्न के आवेदन करने के लिए खुद को उधार दे। ऐसा एक परिदृश्य डेटा बाध्यकारी है। डेटा बाइंडिंग में, स्रोत ऑब्जेक्ट के लिए श्रोता ऑब्जेक्ट से पूरी तरह से स्वतंत्र होना आम है, जो बाध्यकारी का लक्ष्य है। डब्ल्यूपीएफ डेटा बाध्यकारी के कई पहलुओं में पहले से ही कमजोर घटना पैटर्न लागू होता है जिसमें घटनाओं को लागू किया जाता है।

केवल एक ही व्यक्ति है जो उन्हें करने के लिए नकारात्मक किसी भी प्रकार प्रस्तुत किया है इस ब्लॉग है:

:

http://blog.catenalogic.com/post/2011/11/23/A-weak-event-listener-for-WPF-Silverlight-and-Windows-Phone-7.aspx

सामान्य रूप में एक कमजोर घटना श्रोताओं का उपयोग कर के बारे में कुछ कमियां हैं

• यह नोटेशन बदसूरत है, "मूल" .NET तरीका बेहतर तरीके से दिखता है
• तुम स्ट्रिंग द्वारा घटना, कि बेकार है नाम के लिए है (यदि आप एक बेहतर तरीका पता है, मुझे संपर्क!)
• यह केवल eventhandler के हैंडलर के साथ घटनाओं को संभाल सकता है
• आप बन एक आलसी डेवलपर सदस्यता
देखभाल नहीं

मूलतः, वे घटनाओं है कि अपने वस्तुओं अपने अस्तित्व की पूरी लंबाई के लिए करने के लिए सदस्यता, और केवल जब वस्तुओं निपटान से डिस्कनेक्ट के लिए इस्तेमाल किया जाना चाहिए। अन्य सभी चीज़ों के लिए, पारंपरिक घटनाओं का उपयोग करके और घटनाओं को पंजीकरण/अनधिकृत करने के लिए मैन्युअल रूप से प्राथमिकता दी जाती है।

Answer 2

कमजोर घटनाओं का उपयोग कब करें?

MSDN

घटनाओं स्मृति को जन्म दे सकता के लिए सुनकर से लीक

तो तुम उन लीक

से बचने के उद्देश्य के साथ कमजोर घटनाओं का उपयोग करना चाहिए इसका इस्तेमाल करने के लिए अच्छा है यह हर वर्ग जो घटनाओं को उजागर कर रहा है? कमजोर घटनाओं का उदारतापूर्वक उपयोग करने के दुष्प्रभाव क्या हैं?

Why is the implementation of events in C# not using a weak event pattern by default? देखें।"मजबूत" घटनाओं से लीक करना सामान्य नहीं है, कमजोर घटनाएं प्रदर्शन लागत के साथ आती हैं और एक अर्थपूर्ण अंतर होता है जो हर संदर्भ में वांछित नहीं हो सकता है, कमजोर संदर्भ का दुरुपयोग घटना को अंतःस्थापित करने के लिए प्रेरित नहीं कर सकता है (इसके विपरीत एक सामान्य एक स्मृति रिसाव के कारण घटना) का दुरुपयोग

उदाहरण स्मृति रिसाव कि

स्टेटिक कक्षाएं बचा जा सकता है और एकमात्र जब वे किसी अन्य वस्तु वे नहीं कर पाएगा लिए एक संदर्भ के अधिग्रहण, जब मेमोरी लीक के बारे में बात खलनायक हैं वस्तु को कचरा होने से एकत्रित किया जाता है, और इस प्रकार, ऑब्जेक्ट को एप्लिकेशन की उम्र बढ़ने के लिए, here एक उदाहरण है जहां मैं एक यादगार से बचने के लिए एक कमजोर संदर्भ की आवश्यकता से मुलाकात की y

Answer 3

रिसाव दो मुद्दों है कि कमजोर घटनाओं के साथ विचार किया जाना चाहिए रहे हैं:

1. कमजोर घटनाओं ग्राहकों भी वर्ग घटना को ऊपर उठाने की पहचान जानने के बिना घटनाओं (संदेश) की सदस्यता के लिए अनुमति देते हैं। कुछ मामलों में भी वांछित वांछित हो सकता है। हालांकि, कुछ मामलों में जो अनावश्यक जटिलता और संकेत के स्तर को पेश कर सकते हैं जो कोड को रन टाइम पर प्रबंधित या नियंत्रित करने में कठोर बनाता है।
2. कमजोर घटनाओं का उपयोग करने का प्रमुख नकारात्मक पक्ष यह है कि यह डेवलपर्स को उन हिस्सों को अनदेखा करने के लिए प्रोत्साहित कर सकता है जहां वे ईवेंट (संदेश) से सदस्यता छोड़ते हैं। उस स्थिति में उपभोक्ता "दायरे से बाहर निकलने" के बाद भी ईवेंट हैंडलर लगाए जा सकते हैं। एक ऐसे ग्राहक पर विचार करें जो स्पष्ट रूप से सदस्यता समाप्त नहीं करता है और यह कचरा इकट्ठा हो जाता है लेकिन अभी तक कचरा एकत्र नहीं किया गया था। कमजोर घटना प्रबंधक उस राज्य का पता लगाने में सक्षम नहीं होगा और इसके कारण यह अभी भी उस ग्राहक के ईवेंट हैंडलर को कॉल करेगा। यह सभी प्रकार के अप्रत्याशित साइड इफेक्ट्स का कारण बन सकता है।

The Weak Event Pattern is Dangerous पर अधिक जानकारी देखें।
यह source code देखें जो एक कमजोर घटना प्रबंधक के रूप में MvvMCross मैसेजिंग प्लगइन का उपयोग करके इस समस्या को दर्शाता है।