एमवीपी और उपयोगकर्ता नियंत्रण और आमंत्रण

Question

मुझे कुछ एमवीपी स्टफ के आसपास अपना सिर लेने की कोशिश करने में कुछ मजा आता है, क्योंकि यह उपयोगकर्ता नियंत्रण से संबंधित है। मैं .NET WinForms (या इसके करीब कुछ) का उपयोग कर रहा हूं और कंट्रोलर पैटर्न का पर्यवेक्षण कर रहा हूं (ठीक है, मुझे लगता है कि मैं हूं :)।

उपयोगकर्ता नियंत्रण स्वयं एमवीपी आवेदन का हिस्सा है (इसका दृश्य और संबंधित प्रेजेंटर आदि है)। प्रस्तुतकर्ता हमेशा पहले शुरू होता है, और यह मॉडल (ओं) शुरू करता है और फिर दृश्य (ओं) शुरू करता है। व्यू अपना यूआई बनाता है, जिसका हिस्सा यूसी को नया होगा, जो व्यू है।

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

इसके अलावा, डिज़ाइन अनुभव को बदला नहीं जाना चाहिए; IOW व्यू (फॉर्म) का देव बस टूलबॉक्स से उपयोगकर्ता नियंत्रण का चयन करने और इसे किसी फ़ॉर्म पर छोड़ने में सक्षम होना चाहिए।

तो, मेरे प्रश्नों पर। सबसे पहले, मेरी धारणाएं सही से ऊपर हैं? कुछ हद तक गुमराह? गड़बड़? डब्ल्यूटीएफ क्या आप सोच रहे हैं?

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

कोई अन्य विचार, सुझाव, टिप्पणियां खुशी से स्वीकार की गईं।

- nwahmaet

Answer 1

प्रस्तुतकर्ता को प्रस्तुति स्तर में "स्वायत्त स्थिति" के रूप में सोचा जाना चाहिए। इसका मतलब है कि यह सुनिश्चित करने के लिए ज़िम्मेदार है कि मॉडल के राज्य की दृश्य प्रस्तुति सिंक हो रही है। इसका कारण यह है कि एमवीपी का "पैटर्न" अक्सर के dogmatic दृश्य में खो जाता है कैसे चीजों को अलग किया जाना चाहिए। ऐसा लगता है कि मार्टिन फाउलर ने clarify the terminology around the MVP पैटर्न को आजमाने का फैसला किया है।

एमवीपी का मेरा पसंदीदा स्वाद passive view है, इसलिए मेरा उत्तर उस पर आधारित है।

मैं निष्क्रिय दृश्य पैटर्न का उपयोग करके अक्सर उपयोगकर्ता नियंत्रण और रूपों को लागू करता हूं। अनिवार्य रूप से 3 अलग-अलग विन्यास हैं:

1. पदानुक्रम में सभी उपयोगकर्ता नियंत्रणों के लिए एक प्रस्तुतकर्ता। इंटरफ़ेस का उपयोग करके दृश्य को फ़्लैट करें।
2. संयुक्त पेड़ में प्रत्येक उपयोगकर्ता नियंत्रण के लिए एक प्रस्तुतकर्ता। प्रत्येक अभिभावक प्रस्तुतकर्ता अपने बच्चे प्रस्तुतियों को तत्काल और प्रारंभ करने के लिए ज़िम्मेदार है। उपयोगकर्ता नियंत्रण डिज़ाइन समय पर बनाए जाते हैं, और प्रस्तुतकर्ता के बिना काम करने में सक्षम होते हैं (कोई प्रेजेंटेशन व्यवहार नहीं)
3. समग्र पेड़ में प्रत्येक उपयोगकर्ता नियंत्रण के लिए एक प्रस्तुतकर्ता। सभी प्रस्तुतकर्ता एक उच्च स्तरीय नियंत्रक वर्ग के माध्यम से कम से कम युग्मित होते हैं। नियंत्रक वर्ग प्रस्तुतकर्ता को समझने, उन्हें तारों और उनके कार्यक्रमों को समन्वयित करने के लिए ज़िम्मेदार है।

हालांकि यह मेरे लिए अंतिम उपाय (इसकी जटिलता के कारण) का समाधान है, मुझे लगता है कि अंतिम विकल्प वह समाधान है जिसे आप ढूंढ रहे हैं।

Answer 2

आपके प्रश्नों सामान्य है कि योजनाओं की एक किस्म लागू हो सकते हैं है।

इस मामले में मेरा अनुमान है कि आपको ऑब्जर्वर पैटर्न देखना चाहिए।

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

विशिष्ट उदाहरणों के विपरीत विचार उपयोगकर्ता नियंत्रण होंगे। आपके पास यूआई तत्व को उस इंटरफ़ेस को लागू करने की लचीलापन है ताकि आप अपने उपयोगकर्ता नियंत्रण के अतिरिक्त संवाद, पूर्ण रूप आदि का उपयोग कर सकें।

अंत में याद रखें कि उपयोगकर्ता नियंत्रण दृश्य नहीं है बल्कि दृश्य का कार्यान्वयन है। जो भी योजना आप अपनाते हैं, वह परिभाषित कर सकती है कि आप जितना गहराई से देखेंगे और उपयोगकर्ता नियंत्रण उस इंटरफ़ेस को कार्यान्वित करेगा।

Answer 3

मैं इस एप्लिकेशन में कई महीनों के लिए इस सटीक समस्या के खिलाफ दौड़ रहा हूं जिस पर मैं काम कर रहा हूं। निष्कर्ष जो मैंने हाल ही में किया है यह है कि कई मामलों में पैटर्न को "तोड़ने" के बिना खिड़की और उपयोगकर्ता नियंत्रण स्तर दोनों पर एमवीपी पैटर्न लागू करना असंभव हो सकता है।

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

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

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

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