मैंने अतीत में एमवीपी और एमवीसी का उपयोग किया है, और मुझे एमवीपी पसंद है क्योंकि यह मेरे विचार में निष्पादन के प्रवाह को इतना बेहतर नियंत्रित करता है।
मैंने अपना इन्फ्रास्ट्रक्चर (डेटास्टोर / रिपॉजिटरी क्लासेस) बनाया है और हार्ड कोडिंग सैंपल डेटा के बिना इश्यू का इस्तेमाल करते हैं, इसलिए अब मैं जीयूआई पर जा रहा हूं और अपना एमवीपी तैयार कर रहा हूं।
खंड एक
मैंने एमवीपी को प्रवेश बिंदु के रूप में दृश्य का उपयोग करते हुए देखा है, जो कि व्यू कंस्ट्रक्टर विधि में है जो इसे प्रस्तुतकर्ता बनाता है, जो बदले में मॉडल बनाता है, आवश्यकतानुसार घटनाओं को वायरिंग करता है।
मैंने प्रस्तुतकर्ता को प्रवेश बिंदु के रूप में भी देखा है, जहां एक दृश्य, मॉडल और प्रस्तुतकर्ता बनाया जाता है, इस प्रस्तुतकर्ता को घटनाओं को तार करने के लिए इसके निर्माता में एक दृश्य और मॉडल ऑब्जेक्ट दिया जाता है।
जैसा कि 2 में है, लेकिन मॉडल प्रस्तुतकर्ता को पारित नहीं किया गया है। इसके बजाय मॉडल एक स्थिर वर्ग है जहां तरीकों को बुलाया जाता है और प्रतिक्रियाएं सीधे लौटती हैं।
अनुभाग बी
दृश्य और मॉडल को सिंक में रखने के संदर्भ में मैंने देखा है।
जब भी बदले हुए दृश्य में कोई मान होता है, तो
TextChanged.Net / C # में ईवेंट। यह आग हैDataChangedEventजो हर समय सिंक में रखने के लिए, मॉडल के माध्यम से पारित किया जाता है। और जहां मॉडल बदलता है, यानी एक पृष्ठभूमि घटना जिसे वह सुनता है, तो दृश्य को एक ही विचार के माध्यम से अद्यतन किया जाता हैDataChangedEvent। जब कोई उपयोगकर्ता परिवर्तन करना चाहता हैSaveEvent, तो यह आग को बचाने के लिए मॉडल में गुजरता है। इस मामले में मॉडल दृश्य के डेटा की नकल करता है और कार्रवाई करता है।# B1 के समान, हालांकि दृश्य हर समय मॉडल के साथ सिंक नहीं करता है। इसके बजाय जब उपयोगकर्ता परिवर्तन करना चाहता है,
SaveEventतो निकाल दिया जाता है और प्रस्तुतकर्ता नवीनतम विवरणों को पकड़ लेता है और उन्हें मॉडल में पास करता है। इस मामले में मॉडल को उस दृश्य डेटा के बारे में पता नहीं है, जब तक उस पर कार्रवाई करने के लिए आवश्यक नहीं है, उस स्थिति में यह सभी आवश्यक विवरणों को पारित किया जाता है।
अनुभाग सी
दृश्य में व्यावसायिक वस्तुओं का प्रदर्शन, अर्थात कोई वस्तु (MyClass) आदिम डेटा नहीं (int, double)
दृश्य के पास अपने सभी डेटा के लिए संपत्ति फ़ील्ड हैं जो इसे डोमेन / व्यावसायिक वस्तुओं के रूप में प्रदर्शित करेगा। जैसे कि
view.AnimalsएकIEnumerable<IAnimal>संपत्ति को उजागर करता है , भले ही दृश्य इन्हें ट्रीव्यू में नोड्स में संसाधित करता है। तब चयनित जानवर के लिए यह संपत्ति केSelectedAnimalरूप में सामने आएगाIAnimal।दृश्य में डोमेन ऑब्जेक्ट्स का कोई ज्ञान नहीं है, यह आदिम / फ्रेमवर्क (.Net / जावा) के लिए संपत्ति को उजागर करता है जिसमें केवल ऑब्जेक्ट शामिल हैं। इस उदाहरण में प्रस्तुतकर्ता डोमेन ऑब्जेक्ट पर एक एडाप्टर ऑब्जेक्ट को पारित करेगा, एडेप्टर किसी दिए गए व्यावसायिक ऑब्जेक्ट को दृश्य पर दिखाई देने वाले नियंत्रणों में अनुवाद करेगा। इस उदाहरण में एडॉप्टर को दृश्य पर वास्तविक नियंत्रणों तक पहुंच होनी चाहिए, न कि केवल किसी भी दृश्य को और अधिक कसकर युग्मित करने के लिए।
अनुभाग डी
एकल नियंत्रण बनाने के लिए उपयोग किए गए एकाधिक दृश्य। यानी आपके पास एक साधारण मॉडल के साथ एक जटिल दृश्य है जैसे विभिन्न प्रकार की वस्तुओं को सहेजना। आपके पास एक आइटम पर एक मेनू सिस्टम हो सकता है, जिसमें प्रत्येक क्लिक पर उपयुक्त नियंत्रण दिखाए जाते हैं।
आप एक विशाल दृश्य बनाते हैं, जिसमें सभी अलग-अलग नियंत्रण शामिल होते हैं जो कि दृश्य इंटरफ़ेस के माध्यम से उजागर होते हैं।
आपके कई विचार हैं। आप मेनू और एक खाली पैनल के लिए एक दृश्य है। यह दृश्य आवश्यक अन्य दृश्य बनाता है, लेकिन उन्हें प्रदर्शित नहीं करता है (दृश्य = गलत), यह दृश्य उस प्रत्येक दृश्य के लिए इंटरफ़ेस को भी लागू करता है जिसमें यह शामिल है (अर्थात बच्चे के विचार) ताकि यह एक प्रस्तुतकर्ता को उजागर कर सके। रिक्त पैनल अन्य विचारों (
Controls.Add(myview)) और ((myview.visible = true) से भरा है । इन "बाल"-साक्षात्कारों में उठाई गई घटनाओं को माता-पिता के दृष्टिकोण द्वारा नियंत्रित किया जाता है जो बदले में घटना को प्रस्तुतकर्ता को सौंप देते हैं, और बच्चे के तत्वों को वापस करने की घटनाओं के लिए वीज़ा वर्सा देते हैं।प्रत्येक दृश्य, यह मुख्य माता-पिता या छोटे बच्चे के विचार हैं, प्रत्येक को वहां प्रस्तुतकर्ता और मॉडल में वायर्ड किया गया है। आप एक मौजूदा रूप में केवल एक दृश्य नियंत्रण को छोड़ सकते हैं और इसकी कार्यक्षमता तैयार होगी, बस पर्दे के पीछे एक प्रस्तुतकर्ता में तारों की आवश्यकता होती है।
अनुभाग ई
क्या सब कुछ एक इंटरफ़ेस होना चाहिए, अब उपरोक्त उदाहरणों में एमवीपी कैसे किया जाता है इसके आधार पर इस उत्तर को प्रभावित करेगा क्योंकि वे क्रॉस-संगत नहीं हो सकते हैं।
हर चीज में एक इंटरफ़ेस, व्यू, प्रस्तोता और मॉडल होता है। इनमें से प्रत्येक में स्पष्ट रूप से एक ठोस कार्यान्वयन है। यहां तक कि अगर आपके पास केवल एक ठोस दृष्टिकोण, मॉडल और प्रस्तुतकर्ता है।
व्यू और मॉडल में एक इंटरफ़ेस है। यह विचारों और मॉडलों को अलग करने की अनुमति देता है। प्रस्तुतकर्ता दृश्य और मॉडल ऑब्जेक्ट बनाता / देता है और यह केवल उनके बीच संदेश भेजने का कार्य करता है।
केवल दृश्य में एक इंटरफ़ेस है। मॉडल में स्थिर विधियाँ हैं और इसे बनाया नहीं गया है, इस प्रकार इंटरफ़ेस की कोई आवश्यकता नहीं है। यदि आप एक अलग मॉडल चाहते हैं, तो प्रस्तुतकर्ता स्थिर वर्ग विधियों का एक अलग सेट कहता है। मॉडल स्थिर होने से प्रस्तुतकर्ता के लिए कोई लिंक नहीं है।
व्यक्तिगत विचार
मेरे द्वारा प्रस्तुत किए गए सभी विभिन्न रूपों से (ज्यादातर मैंने शायद किसी रूप में उपयोग किया है) जिनमें से मुझे यकीन है कि कुछ और भी हैं। मैं कम से कम डेटा दोहराव और कम घटनाओं को निकाल दिया जा रहा है के लिए एमवीपी, बी 2 के बाहर व्यापार तर्क को पुन: प्रयोज्य रखने के रूप में A3 को प्राथमिकता देता हूं। C1 को किसी अन्य वर्ग में नहीं जोड़ने के लिए, सुनिश्चित करें कि यह एक छोटी मात्रा में गैर-इकाई परीक्षण योग्य तर्क को एक दृश्य में रखता है (एक डोमेन ऑब्जेक्ट की कल्पना कैसे की जाती है) लेकिन यह कोड की समीक्षा की जा सकती है, या बस एप्लिकेशन में देखी जा सकती है। यदि तर्क जटिल था, तो मैं एक एडेप्टर वर्ग से सहमत होगा, लेकिन सभी मामलों में नहीं। खंड डी के लिए, मुझे लगता है कि डी 1 एक ऐसा दृश्य बनाता है जो मेनू उदाहरण के लिए बहुत बड़ा है। मैंने पहले भी डी 2 और डी 3 का उपयोग किया है। D2 के साथ समस्या यह है कि आप अंत में प्रस्तुतकर्ता से सही बच्चे को देखने के लिए मार्ग घटनाओं के लिए बहुत सारे कोड लिखने के लिए, और इसके ड्रैग / ड्रॉप संगत नहीं हैं, प्रत्येक नए नियंत्रण को एकल प्रस्तुतकर्ता का समर्थन करने के लिए अधिक तारों की आवश्यकता होती है। डी 3 मेरी पसंद की पसंद है लेकिन दृश्य से निपटने के लिए प्रस्तुतकर्ता और मॉडल के रूप में अभी तक अधिक कक्षाओं में जोड़ता है, भले ही दृश्य बहुत सरल हो या फिर पुन: उपयोग करने की कोई आवश्यकता न हो। मुझे लगता है कि डी 2 और डी 3 का मिश्रण परिस्थितियों पर आधारित है। खंड ई के रूप में, मुझे लगता है कि एक इंटरफ़ेस वाले सब कुछ ओवरकिल हो सकता है मैं इसे पहले से ही डोमेन / व्यावसायिक वस्तुओं के लिए करता हूं और अक्सर ऐसा करके "डिजाइन" में कोई फायदा नहीं दिखता है, लेकिन यह परीक्षणों में वस्तुओं का मजाक उड़ाने में मदद करता है। व्यक्तिगत रूप से मैं E2 को एक क्लासिक समाधान के रूप में देखूंगा, हालाँकि मैंने E3 को उन 2 परियोजनाओं में उपयोग किया है जिन्हें मैंने पहले काम किया है। मुझे लगता है कि डी 2 और डी 3 का मिश्रण परिस्थितियों पर आधारित है। खंड ई के रूप में, मुझे लगता है कि एक इंटरफ़ेस वाले सब कुछ ओवरकिल हो सकता है मैं इसे पहले से ही डोमेन / व्यावसायिक वस्तुओं के लिए करता हूं और अक्सर ऐसा करके "डिजाइन" में कोई फायदा नहीं दिखता है, लेकिन यह परीक्षणों में वस्तुओं का मजाक उड़ाने में मदद करता है। व्यक्तिगत रूप से मैं E2 को एक क्लासिक समाधान के रूप में देखूंगा, हालाँकि मैंने E3 को उन 2 परियोजनाओं में उपयोग किया है जिन्हें मैंने पहले काम किया है। मुझे लगता है कि डी 2 और डी 3 का मिश्रण परिस्थितियों पर आधारित है। खंड ई के रूप में, मुझे लगता है कि एक इंटरफ़ेस वाले सब कुछ ओवरकिल हो सकता है मैं इसे पहले से ही डोमेन / व्यावसायिक वस्तुओं के लिए करता हूं और अक्सर ऐसा करके "डिजाइन" में कोई फायदा नहीं दिखता है, लेकिन यह परीक्षणों में वस्तुओं का मजाक उड़ाने में मदद करता है। व्यक्तिगत रूप से मैं E2 को एक क्लासिक समाधान के रूप में देखूंगा, हालाँकि मैंने E3 को उन 2 परियोजनाओं में उपयोग किया है जिन्हें मैंने पहले काम किया है।
सवाल
क्या मैं एमवीपी को सही तरीके से लागू कर रहा हूं? क्या इसके बारे में जाने का एक सही तरीका है?
मैंने मार्टिन फाउलर के काम को पढ़ा है जिसमें विविधताएं हैं, और मुझे याद है कि जब मैंने पहली बार एमवीसी करना शुरू किया था, तो मैं अवधारणा को समझ गया था, लेकिन मूल रूप से यह काम नहीं कर सका कि प्रवेश बिंदु कहां है, सब कुछ का अपना कार्य है लेकिन क्या नियंत्रण करता है और मूल बनाता है MVC ऑब्जेक्ट्स का सेट।