कैसल विकी यहां थोड़ा सख्त है - क्षमा करने के बजाए सुरक्षित होने की कोशिश कर रहा है। यह शायद कुछ rewording का उपयोग कर सकता है।
वैसे भी - यह कैसे काम करता है।
विंडसर (डिफ़ॉल्ट रूप से) अधिकांश घटकों को ट्रैक करता है और यह उनको संदर्भित करता है जो कचरा कलेक्टर को इकट्ठा करने से रोकते हैं। यह एक बग नहीं है - यह एक विशेषता है, और एक बेहद उपयोगी और शक्तिशाली है। ज्यादातर मामलों में आपको यह नहीं मानना चाहिए कि कोई घटक ट्रैक किया जाएगा या नहीं। एक गैर-डिस्पोजेबल घटक जिसमें डिस्पोजेबल निर्भरताएं भी ट्रैक की जाएंगी। यह सामान्य नियम में है: "घटक जो स्वयं अपनी कुछ निर्भरताओं में से हैं, विंडसर में डिफ़ॉल्ट रिलीज नीति द्वारा किसी भी डिमोकेशन चरणों को ट्रैक किया जाता है"।
अब, वह हिस्सा है जहां जीवनकाल खेलता है।
सिंगलटन - वे बनाए गए हो जब आप पहली बार उन्हें अनुरोध और कंटेनर (जब तक कंटेनर निपटारा हो जाता है जिसका अर्थ है की जीवन के बाकी के लिए रहते हैं - परिभाषा सिंगलटन द्वारा "वैश्विक" कंटेनर के संदर्भ में कर रहे हैं)। यदि आप दस्तावेज़ीकरण देखते हैं, तो यह वास्तव में कहता है कि सिंगलटन जारी करना वास्तव में कुछ भी नहीं करता है। यह तभी होता है जब कंटेनर का निपटारा हो जाता है कि आपके जीवनकाल घटकों की डिमोकिशन चिंताओं को बुलाया जाएगा।
प्रति (संदर्भ: वेब अनुरोध/डब्ल्यूसीएफ सत्र /) - चूंकि ऑब्जेक्ट को अच्छी तरह परिभाषित संदर्भ में एक अच्छी परिभाषित संदर्भ में साझा किया जाता है, संदर्भ के अंत आपके घटकों को जारी करने का ख्याल रखेंगे।
क्षणिक - यही वह जगह है जहां असली समस्याएं रेंग सकती हैं। चूंकि क्षणिक घटकों का जीवनकाल का अंतहीन अंत नहीं होता है और आप ऐप के जीवनकाल के दौरान अपने उदाहरणों के ढेर का उत्पादन कर सकते हैं, वहां होने से कोई दूसरा रास्ता नहीं है कंटेनर को स्पष्ट और कह रहा है "अरे, मैं अब इस वस्तु का उपयोग नहीं कर रहा हूं, इससे छुटकारा पाने के लिए स्वतंत्र महसूस करें, सभी मछलियों के लिए धन्यवाद।"
अब कारण है कि दस्तावेज हमेशा घटकों को जारी करने का सुझाव देते हैं कि घटकों का उपयोग करने वाले कोड को वास्तव में पता नहीं होना चाहिए कि घटक का जीवनकाल क्या है। यह हमेशा मामला नहीं है, और अक्सर अनुप्रयोगों में ऐसे घटक होते हैं जो "स्वाभाविक रूप से" जीवन शैली में फिट होते हैं। आम तौर पर, जैसा कि मैंने कहा था कि यह क्षमा के बजाय सुरक्षित होने के बारे में है।
एक और बात यह है कि आप Resolve और Release पर कॉल करते हैं। आपको केवल Release क्या होना चाहिए Resolve।
जब आप कंटेनर in similar manner to how I do it का उपयोग करते हैं, तो आपको अपने कोड में कहीं भी Release पर कॉल करने की आवश्यकता नहीं हो सकती है। आप Resolve अपनी रूट करेंगे, लेकिन कंटेनर के Dispose स्वयं इसे जारी करने का ख्याल रखेंगे। आप टाइप किए गए कारखानों के माध्यम से अन्य घटकों को पूरी तरह से हल करेंगे, और इस मामले में आपको उन्हें (फैक्ट्री के माध्यम से) भी जारी करना चाहिए, लेकिन आमतौर पर यह आमतौर पर होता है।
तो अंतिम परिणाम यह है कि यह पहले जैसा लगता है उतना डरावना नहीं है।
स्रोत
2010-07-26 11:41:55
धन्यवाद Krzysztof! यही वह जवाब था जिसे मैं ढूंढ रहा था। रिलीज और कंटेनर के संबंध में: "सेवा लोकेटर पैटर्न" से बचने के लिए आपकी सिफारिश (आसपास कंटेनर से बचने से बचें) बिल्कुल सही है। मैं मुख्य रूप से सवाल पूछ रहा था क्योंकि फैक्ट्री सुविधा द्वारा बनाई गई कारखानों के लिए "रिलीज प्रश्न" समान है। – blueling
Krzysztof द्वारा समझाए गए नियमों के लिए एक चेतावनी यह है कि यदि आप स्वयं ऑब्जेक्ट बनाते हैं और कंटेनर के साथ अपना उदाहरण पंजीकृत करते हैं (बल्कि कंटेनर आपके लिए एक उदाहरण बनाते हैं), तो कंटेनर उस इंस्टेंस के जीवन चक्र के प्रबंधन को छोड़ देगा आप। अर्थात। भले ही आप इसे सिंगलटन के रूप में पंजीकृत करते हैं, कंटेनर कंटेनर का निपटान करते समय इसका निपटान नहीं करेगा। –
सही। आखिरकार यह तय करने के लिए 'ILifestyleManager' के लिए है, और आने वाले विंडसर 3 लाइफस्टाइल प्रबंधकों के यहां और भी अधिक नियंत्रण है। –