जीवित रहने के बिना एमवीसी पैटर्न को कार्यान्वित करने के लिए कैसे

Question

मैं एक कठिन परिस्थिति में एमवीसी पैटर्न को कार्यान्वित करना चाहता हूं। कठिनाई यह है कि मेरे मॉडल (घटनाओं को उत्पन्न करने वाली संस्थाएं) लंबे समय तक जीवित हैं, जबकि दृश्य (घटनाओं के रिसीवर) अल्पकालिक हैं। मेरी समस्या यह है कि दोनों के बीच संबंध के माध्यम से, लंबे समय तक रहने वाले मॉडल मेरे अल्पकालिक दृश्यों को जीवित रखते हैं, यानी वे कचरे से एकत्र नहीं हो सकते हैं।

[MODEL] ------- <weak> -------> [VIEW] 
    | 
<strong> 
    | 
    v 
[CONTROLLER] 

इससे बचने के लिए एक तरह से एक WeakHashMap < दृश्य में, नियंत्रक > मॉडल में कनेक्शन स्टोर करने के लिए है। यह अनिवार्य रूप से दृश्य को कचरा इकट्ठा करने देता है, और जब ऐसा होता है, तो WeakHashMap संबंधित नियंत्रक को भी फेंक देगा। यही है, अगर नियंत्रक दृश्य के लिए एक (मजबूत) संदर्भ नहीं रखता है - जो आमतौर पर करता है। इस मामले में जब तक मॉडल गुंजाइश से बाहर नहीं जाता तब तक दृढ़ संदर्भों के माध्यम से दृश्यों को जीवित रखा जाता है।

[MODEL] ------- <weak> -------> [VIEW] 
    |        ^
<strong>       | 
    |        | 
    v        | 
[CONTROLLER] ----------- <strong> ---/ 

श्रोताओं को मेरे मॉडल में संलग्न करने का कोई और तरीका है जो मेरे विचार (और नियंत्रक) को जीवित नहीं रखेगा?

अद्यतन: एमडीएमए के सवाल का जवाब करने के लिए: क्योंकि यह दृश्य को अपडेट करना होगा नियंत्रक, देखें के लिए एक संदर्भ रहता है। यह संदर्भ कमजोर हो सकता है, लेकिन मैं नियंत्रक को व्यू क्लास के अज्ञात आंतरिक-कक्षाएं रखना चाहता हूं, इस स्थिति में नियंत्रक उदाहरण के दृश्य उदाहरण के लिए एक अंतर्निहित मजबूत संदर्भ है।

Answer 1

Here आपको एमवीसी पैटर्न का एक बड़ा कार्यान्वयन मिला है। शायद आपकी समस्या का समाधान है।

Answer 2

एमवीसी करने के कुछ तरीके हैं।

• एक मॉडल लिखें तो अपने विचार को मॉडल में बदलावों को सुनें। जब कुछ भी होता है तो दृश्य नियंत्रक को बताता है।
• एक दृश्य लिखें फिर अपने मॉडल को देखने के लिए परिवर्तनों को सुनें। जब कुछ भी होता है तो दृश्य नियंत्रक को बताता है।
• एक दृश्य लिखें। अपने मॉडल को देखने के लिए परिवर्तनों को सुनें। अपने नियंत्रक को दृश्य को सुनें, जो कुछ भी होने पर अलग-अलग घटनाओं को उठाएगा।

अंतिम व्यक्ति विचारों, नियंत्रकों और मॉडलों के बीच सबसे कमजोर युग्मन प्रदान करता है। यह नियंत्रक को यूनिट-टेस्ट करने के लिए एक बेस्टर्ड है क्योंकि आप ईवेंट हैंडलर को स्टब करना चाहते हैं। आप नकली ढांचे का उपयोग करके उन्हें नकल भी नहीं कर सकते हैं, क्योंकि आपको पूरे समय घटनाओं को बढ़ाने की जरूरत है। यह काम करता है, यद्यपि।

• एक प्रस्तुतकर्ता में मॉडल रैप करने के लिए अपने नियंत्रक की अनुमति दें:

  मैं MVCP पसंद है। नियंत्रक संलग्न होने के लिए सुनता है, और हर बार उन्हें एक नया प्रस्तुतकर्ता हाथ देता है। प्रेजेंटर मॉडल में फ़ील्ड में परिवर्तन करता है, और कंट्रोलर को कमांड का प्रतिनिधि भी देता है। न तो नियंत्रक और न ही मॉडल प्रस्तुतकर्ता के संदर्भ में लटकता है। जब दृश्य मर जाता है, तो प्रस्तुतकर्ता इसके साथ जाता है।

प्रस्तुतकर्ताओं बारे में महान बात आप सिर्फ उस दृश्य की जरूरत सामान संपुटित कर सकते हैं। एक प्रस्तुतकर्ता के लिए इंटरफेस लगभग पूरी तरह से दृश्य द्वारा संचालित है। आप अलग-अलग विचारों के लिए विभिन्न प्रस्तुतियां बनाने जैसी चीजें भी कर सकते हैं, और इन्हें एक इंटरफ़ेस विधि के माध्यम से इस तरह पॉप्युलेट कर सकते हैं: Presenter.PopulateWith(model, controller)।यह आपको अपने प्रस्तुति तर्क को प्रदूषित किए बिना सभी प्रस्तुतिकरण तर्क (तारों में दिनांक, . आदि के बिना लॉगिन नाम) करने के लिए एक शानदार जगह प्रदान करता है। और आप मुफ्त में अपना कमजोर संदर्भ प्राप्त करते हैं!

यह एमवीवीएम पैटर्न के समान है जो अब idiomatic WPF में उपयोग किया जाता है। वेब के साथ जावा में भी अच्छा काम करता है। आशा है कि ये आपको कुछ विचार दें, वैसे भी।

Answer 3

मुझे लगता है कि आप सही रास्ते पर बहुत अधिक हैं। मैं विचारों को ठीक से पुन: दावा प्राप्त करने के लिए दो संभव समाधान देखें:

1. डिजाइन प्रणाली में दृश्य जीवनकाल, जिससे कि दृश्य descruction स्पष्ट रूप से किया जाता है, और सभी इच्छुक पार्टियों तो देखने के लिए उनके संदर्भ जारी कर सकते हैं।

2. नियंत्रक में मजबूत संदर्भ को हटाएं। नियंत्रक या तो दृश्य को पकड़ने के लिए एक वीक रेफरेंस का उपयोग कर सकता है, जिसे प्रत्येक एक्सेस के साथ चेक किया जाना चाहिए, या इसके बजाय, नियंत्रक को एक व्यू कार्यान्वयन पास करें जो आपके असली दृश्य में प्रतिनिधि होता है, जो इसे कमजोर संदर्भ के माध्यम से पकड़ता है। यदि संदर्भ पुनः दावा किया गया है (शून्य है) विधि कॉल एक नो-ऑप है।

Answer 4

... लेकिन मैं दृश्य वर्ग की अनाम भीतरी कक्षाएं, जो मामले में नियंत्रक उदाहरण देखें उदाहरण के लिए एक अंतर्निहित मजबूत संदर्भ में है होना करने के लिए नियंत्रकों करना चाहते हैं।

यह प्रश्न में आरेखों के आधार पर काम नहीं करेगा ...

एक नियमित देखें Controller में Controller और एक अन्य को Model में संदर्भ मतलब है कि View दृढ़ता से पहुंचा जा सकता है पर्याप्त होगा। नतीजतन Controller में View में कमजोर संदर्भ टूटा नहीं जाएगा ... जब तक Model स्वयं कचरा संग्रह के लिए योग्य नहीं हो जाता है।

चूंकि एक अज्ञात भीतरी कक्षा कभी स्थिर नहीं हो सकती है, इसलिए आपके पास कोई समझदार विकल्प नहीं है (*) लेकिन नियंत्रक को एक स्थिर नेस्टेड क्लास या गैर-नेस्टेड क्लास बनाने के लिए।

दूसरा विकल्प मॉडल से नियंत्रक को लिंक को कमजोर संदर्भ बनाना होगा।

_{(* असल में। एक चाल है कि संभवतः काम कर सकते हैं ... यह लगभग भी भयानक उल्लेख करने के लिए है, हालांकि वहाँ आप यह पता लगाने सकता है क्या छिपा विशेषता है कि इसके जनक वस्तु के लिए नियंत्रक वस्तु की कड़ी रखती है का नाम है, और हो सकता है प्रतिबिंब का उपयोग Field खोजने के लिए और उसके बाद का उपयोग करें कि null को विशेषता निर्धारित करने में।)}

---

संपादित

यह वही जम्मू है एलएस अज्ञात कक्षाओं के बारे में कहता है - JLS 15.9.1

एक अज्ञात वर्ग कभी सार (§8.1.1.1) नहीं है। एक अज्ञात वर्ग हमेशा एक आंतरिक वर्ग (§8.1.3) है; यह कभी स्थिर नहीं है (§8.1.1, §8.5.2)। एक अज्ञात वर्ग हमेशा निहित है (§8.1.1.2)।

मैं कठिनाई ओपी की टिप्पणी के साथ इस का मिलान हो रही है ...