क्या MVC में 'C' वास्तव में आवश्यक है?


37

मैं मॉडल-व्यू-कंट्रोलर पैटर्न में मॉडल और दृश्य की भूमिका को समझता हूं, लेकिन मुझे यह समझने में कठिन समय है कि नियंत्रक क्यों आवश्यक है।

मान लेते हैं कि हम MVC दृष्टिकोण का उपयोग करके एक शतरंज कार्यक्रम बना रहे हैं; खेल राज्य मॉडल होना चाहिए, और जीयूआई दृश्य होना चाहिए। वास्तव में इस मामले में नियंत्रक क्या है?

क्या यह सिर्फ एक अलग वर्ग है जिसमें सभी फ़ंक्शन हैं जिन्हें आपको कॉल करने पर कहा जाएगा, एक टाइल पर क्लिक करें? केवल दृश्य में ही मॉडल पर सभी तर्क क्यों नहीं करते हैं?


1
व्यक्तिगत रूप से, मैं यही करता हूंऐसे मामले हो सकते हैं जहां एमवीसी का कोई विकल्प नहीं है, लेकिन मैं इसे बर्दाश्त नहीं कर सकता।
माइक डनलैवी

10
तीन शब्द ... "चिंता का पृथक्करण"।
ट्रैविस जे

4
लगभग सभी विंडोज़ प्रोग्रामों ने पहले .net का इस्तेमाल नो-कंट्रोलर के साथ डॉक्टर-व्यू के लिए किया था। यह अपेक्षाकृत सफल रहा है।
मार्टिन बेकेट

मार्टिन, संयुक्त राष्ट्र (परिवर्तन) सक्षम मोनोलिट्स।
स्वतंत्र

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

जवाबों:


4

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

ऐसे समय होते हैं जब सभी नियंत्रक एक साइन अप पृष्ठ की तरह आगे और पीछे की जानकारी पास करते हैं। अन्य बार नियंत्रक विकास का कठिन हिस्सा होता है क्योंकि कई चीजें हैं जो उस स्तर पर की जानी चाहिए जैसे कि नियमों को लागू करना या उदाहरण के लिए जटिल गणित करना। नियंत्रक मत भूलना!


36
"आपके उदाहरण का उपयोग करते हुए नियंत्रक ने निर्णय लिया कि कानूनी कदम क्या था या नहीं"। यह खराब उदाहरण है :( ऐसा तर्क मॉडल में भी होगा। अन्यथा आपका तर्क नियंत्रक और मॉडल के बीच विभाजित है।
Dime

6
@ समय - मॉडल में कोई तर्क नहीं होना चाहिए। नियंत्रक एक होल्डिंग तर्क होगा, इसलिए "नियंत्रित करना" होगा।
ट्रैविस जे

34
@TravisJ वहाँ काफी सहमत नहीं हैं। नियंत्रण का अर्थ यह नहीं है कि नौकरी कैसे करना है। यह उन वस्तुओं को नियंत्रित करने के बारे में है जो करते हैं। इसलिए काम करने के लिए तर्क मॉडल में होगा और नियंत्रक नियंत्रित करेगा कि किस मॉडल का उपयोग कार्रवाई की आवश्यक आवश्यकताओं को पूरा करने के लिए किया जाए आदि। मेरे विचार में नियंत्रकों में बहुत तर्क नियंत्रक ब्लॉट के लिए नुस्खा होगा ...
dreza

25
OOP का पूरा बिंदु डेटा और व्यवहार का एक-दूसरे से जुड़ाव और राज्य को आंतरिक रूप से घेरना है। "मॉडल" व्यवहार और डेटा दोनों को मॉडल करता है।
मिसको

12
-1 नियंत्रक के पास व्यावसायिक तर्क नहीं होना चाहिए । मॉडल है "एप्लिकेशन", यह डेटा रखती है और सब कुछ है कि कर सकते हैं के लिए प्रतिदेय दिनचर्या है ऐसा ऐप्लिकेशन में; जरूरी नहीं कि सभी एक ही फाइल या क्लास में हों। दृश्य मॉडल की स्थिति को दर्शाता है। नियंत्रक मॉडल / दृश्य और वास्तविक दुनिया / इनपुट को पुल करता है। ऐप को वेब ऐप के रूप में "प्रकाशित" करना चाहते हैं ? बस एक नियंत्रक की आवश्यकता है जो HTTP और एक उपयुक्त HTML- आधारित दृश्य को संभालता है। अपने ऐप में कमांड लाइन इंटरफ़ेस चाहते हैं? बस एक उपयुक्त नियंत्रक और दृश्य की आवश्यकता है। मॉडल, व्यावसायिक तर्क, इन मामलों में कभी नहीं बदलता है।
छल

39

केवल दृश्य में ही मॉडल पर सभी तर्क क्यों नहीं करते हैं?

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

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

मॉडल को रखने और अलग देखने से आपको क्या मिलता है:

  • आप दूसरे को बदले बिना मॉडल या दृश्य को बदल सकते हैं। आपको किसी एक को बदलने पर कंट्रोलर को अपडेट करना पड़ सकता है, लेकिन एक तरह से यह फायदे का हिस्सा है: प्रोग्राम के जिन हिस्सों में बदलाव की सबसे अधिक संभावना है, वे कंट्रोलर में केंद्रित होते हैं।

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

  • यह सुनिश्चित करने के लिए दोनों मॉडल और देखने के लिए परीक्षण लिखना आसान है कि वे जिस तरह से काम करना चाहिए।

  • मॉडल और दृश्य दोनों अक्सर मानक भागों का लाभ उठा सकते हैं: सरणियाँ, नक्शे, सेट, तार और मॉडल के लिए अन्य डेटा कंटेनर; बटन, नियंत्रण, टेक्स्ट फ़ील्ड, छवि दृश्य, टेबल और अन्य दृश्य के लिए।


1
डेस्कटॉप अनुप्रयोगों के लिए मूल MVC आर्किटेक्चर में, दृश्य सक्रिय कक्षाएं थीं, सीधे मॉडल का निरीक्षण करते हुए, और नियंत्रक से डिस्कनेक्ट किया गया।
केविन क्लाइन

सभी उत्तरों के साथ समस्या यह है कि पोस्ट करने वाले लोगों के रूप में एमवीसी की कई व्याख्याएं हैं। और ऊपर सूचीबद्ध लाभ केवल एमवीसी की एक विशिष्ट व्याख्या पर लागू होते हैं। यदि कोई अधिकांश तर्क नियंत्रक (या मॉडल) में डाल सकता है और नियंत्रक पर View call / आरंभ विशिष्ट विधि कॉल करता है तो यह नियंत्रक / मॉडल कॉम्बो स्टैंडअलोन और बहुत पुन: प्रयोज्य बनाता है। अधिकांश समय यह एक नया दृष्टिकोण है जिसकी आवश्यकता है। मुझे कभी भी किसी दृश्य का पुन: उपयोग करने की आवश्यकता नहीं हुई। यहां तक ​​कि आपके आरएसएस के उदाहरण को आसानी से एक नए दृश्य के साथ संभाला जा सकता है जो आपके पुराने को बीच में आरएसएस की परत के साथ उपयोग करता है।
डंक

2
@ डंक: बिजनेस लॉजिक को यूजर इंटरफेस से अलग करना जरूरी है ताकि बिजनेस लॉजिक को सीधे टेस्ट किया जा सके।
केविन क्लाइन

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

1
@ डंक: मुझे लगता है कि आप "नियंत्रक" की तरह कुछ भी कॉल कर सकते हैं, लेकिन एमवीसी आर्किटेक्चर में, नियंत्रक निर्भर है और इसलिए उपयोगकर्ता इंटरफ़ेस का हिस्सा है।
केविन क्लाइन

7

इस सामान्य डिजाइन पैटर्न को लागू करने के कई, कई अलग-अलग तरीके हैं, लेकिन मूल विचार विभिन्न चिंताओं को आवश्यकतानुसार अलग करना है। MVC इस अर्थ में एक अच्छा अमूर्त है:

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

यह बेहद लचीला है क्योंकि यह पूरी तरह से निर्दिष्ट नहीं करता है। बहुत से लोग बहुत सारे बैंडविड्थ को बर्बाद करते हैं जो प्रत्येक तत्व के विवरण का तर्क देते हुए बताते हैं कि इन के बजाय किन नामों का उपयोग किया जाना चाहिए, और क्या वास्तव में 3 या 2 या 4 या 5 घटक होना चाहिए, लेकिन यह बिंदु को याद नहीं कर रहा है निश्चित डिग्री।

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

आप सभी को वास्तव में चिंता होनी चाहिए।


3
गोंद, गोंद, मुझे वह परिभाषा पसंद है, यह बहुत सही है: पूरे मॉडल को एमवीजी नाम दिया जाना चाहिए और लोग लालित्य की तलाश में अपने सिर को खरोंचना बंद कर देंगे जहां कोई खोजने के लिए नहीं है।
ZJR

1
"गोंद" के लिए +1; इसका अर्थ यह भी है कि यह एक ऐसा भाग है जो स्क्रिप्टिंग भाषा में किए जाने के लिए सबसे उपयुक्त है (जैसा कि वे ग्लूइंग में बढ़ जाते हैं)।
डोनाल्ड फेलो

@DonalFellows मुझे बहुत अच्छा लगा। कुछ है कि "glues" 2 अलग-अलग संस्थाओं को एक साथ लचीलेपन की बहुत आवश्यकता होती है, जो कमजोर रूप से टाइपिंग की गई भाषाएं (यानी जावास्क्रिप्ट) को बढ़ावा देते हैं
Zack Macomber

4

अब तक के सभी अच्छे जवाब। मेरे दो सेंट यह है कि मैं नियंत्रक के बारे में सोचना पसंद करता हूं क्योंकि मुख्य रूप से क्या और कहां जैसे सवालों के साथ बनाया जा रहा है?

  • मुझे पूछा गया है कि क्या शतरंज के टुकड़े (दृश्य) को x में स्थानांतरित किया जा सकता है। क्या इसकी
    अनुमति है? मुझे यकीन नहीं है, लेकिन मुझे पता है कि कहां और किसे पूछना है (मॉडल)।
  • कुछ ने मुझे अपना डेटा बचाने के लिए कहा है। मैं यह कैसे कर सकता हूँ? मुझे पता है कि कहाँ से पूछना है! हम डेटा को कैसे सहेजते हैं, या इसे कहाँ सहेजा जाता है, मुझे कोई पता नहीं है, लेकिन उस रिपॉजिटरी वर्ग को पता होना चाहिए। मैं इसे अग्रेषित करूंगा और इसे इससे निपटने दूंगा।
  • मुझे उपयोगकर्ता को वर्तमान शतरंज टुकड़ा स्थिति दिखाने के लिए मिला है कि मॉडल ने इसे स्थानांतरित कर दिया है। निश्चित नहीं है कि क्या मैं टुकड़े को हरा या पीला दिखाना चाहता हूं? बाह, जो परवाह करता है, मुझे पता है कि एक दृश्य है जो इसे संभाल सकता है इसलिए मैं उन्हें डेटा पास कर दूंगा और वे तय कर सकते हैं कि यह कैसे दिखाया जाएगा।

ये छोटे स्निपेट इस बात के उदाहरण हैं कि मैं अमूर्त को याद करने की कोशिश कर रहा हूं और अवधारणा एमवीसी को व्यक्त करने की कोशिश कर रही है। क्या, कहां, और कैसे मेरी तीन मुख्य विचार प्रक्रियाएं हैं।

क्या और कहाँ => नियंत्रक कैसे और कब => मॉडल और विचार

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


2

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

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


2

यह वास्तव में खेल में आता है जब आप ईवेंट हैंडलर के साथ काम कर रहे होते हैं, लेकिन आपको व्यू और मॉडल के बीच इंटरैक्शन को संभालने के लिए कंट्रोलर की आवश्यकता होती है। आदर्श रूप से आप मॉडल के बारे में कुछ भी जानना नहीं चाहते हैं। इसके बारे में सोचें, क्या आप चाहते हैं कि सभी डेटाबेस कॉल सीधे करें? (जब तक कि यह लॉगिन लुकअप की तरह कुछ न हो।) आप चाहते हैं कि डेटा रेंडर हो जाए और कोई व्यावसायिक तर्क न हो, जब तक कि यह रेंडरिंग लॉजिक नहीं, लेकिन बिजनेस लॉजिक पियर्स हो।

जीडब्ल्यूटी में, आपको एमवीपी के साथ एक क्लीनर जुदाई मिलती है। देखने में कोई भी व्यावसायिक तर्क नहीं है (यदि यह सही है)। प्रस्तुतकर्ता नियंत्रक के रूप में कार्य करता है और दृश्य को मॉडल का कोई ज्ञान नहीं होता है। मॉडल डेटा को केवल दृश्य पर पास किया जाता है।


1

दस्तावेज़-देखें (यानी मॉडल दृश्य) MFC में लिखे गए अधिकांश विंडोज़ ऐप्स के लिए मानक मॉडल है, इसलिए इसे बहुत सारे मामलों में काम करना चाहिए।


1

मैं मॉडल-व्यू-कंट्रोलर पैटर्न में मॉडल और दृश्य की भूमिका को समझता हूं, लेकिन मुझे यह समझने में कठिन समय है कि नियंत्रक क्यों आवश्यक है।

क्या आप इसके बारे में निश्चित हैं? (कम से कम मूल रूप से वर्णित) मॉडल का बिंदु डोमेन मॉडल होना है। दृश्य उपयोगकर्ता को डोमेन मॉडल प्रदर्शित करने वाला है। नियंत्रक को निम्न स्तर के इनपुट को उच्च स्तर के मॉडल बोलने के लिए माना जाता है। जहाँ तक मैं बता सकता हूँ कि तर्क कुछ इस प्रकार है: A) SRP का एक उच्च स्तरीय उपयोग। बी) मॉडल को ऐप का महत्वपूर्ण हिस्सा माना गया था ताकि महत्वहीन और तेजी से बदलते सामान को बाहर रखें। सी) आसानी से परीक्षण करने योग्य (और स्क्रिप्ट-सक्षम) व्यावसायिक तर्क।

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

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


0

मुझे लगता है कि एमवीसी गूंगा है, हो सकता है कि विशिष्ट क्षेत्रों में यह अच्छी तरह से काम करता हो, लेकिन व्यक्तिगत रूप से भी मेरे द्वारा लिखी गई वेबसाइटें एमवीसी के अनुकूल नहीं हैं। वहाँ एक कारण है कि आप फ्रंटएंड, बैकएंड और कभी डेटाबेस-एंड या कुछ-और-एंड क्यों नहीं सुनते हैं

IMO में एक API (बैकएंड) होना चाहिए और वह ऐप जो API (फ्रंटेंड) का उपयोग करता है। मुझे लगता है कि आप GET अनुरोध नियंत्रक (जिसे बस बैकएंड एपी कहते हैं) और HTML दृश्य को कॉल कर सकते हैं, लेकिन मैं आमतौर पर लोगों को शुद्ध HTML के रूप में देखने के बारे में बात नहीं करता और न ही मॉडल बैकएंड एपीआई के रूप में देखता हूं।

IMO सब कुछ एक ठोस एपीआई होना चाहिए। वास्तव में उन्हें ठोस (साफ और अच्छी तरह से निर्मित) होने की आवश्यकता नहीं है, लेकिन इसके इंटर्न को निजी रहना चाहिए और एप के बाहर / सामने / ऐप को डेटाबेस कनेक्शन कभी नहीं कहना चाहिए और न ही कच्चे प्रश्न करने में सक्षम होना चाहिए।

अब यदि आपके कोड / डिज़ाइन में इसका जुर्माना गोंद है। अगर आपके शतरंज के खेल में कुछ मार्कअप है, तो आप GUI को स्किन एडिट कर सकते हैं, gui कोऑर्डर्स / इनपुट इकट्ठा करते हैं और MovePhew (srcPosition, dstPostion) को कॉल करते हैं (जो कि एक वैध कदम है या नहीं यह कहने के लिए एक बूल या एनम वापस कर सकते हैं या नहीं ) और मॉडल में सभी तर्क होने के साथ आपका ओके तो निश्चित रूप से इसे एमवीसी कहें। हालाँकि, मैं अभी भी कक्षाओं और एपीआई द्वारा चीजों को व्यवस्थित करूँगा और सुनिश्चित करूँगा कि कोई भी रसोई-सिंक क्लास न हो जो हर चीज को छूती हो (और न ही किसी एपीआई को हर चीज के बारे में पता होना चाहिए)।


आपकी राय में आपका स्वागत है, लेकिन यह जवाब ओपी के सवाल का जवाब देने का प्रयास नहीं करता है।
कालेब

0

एक ब्राउज़र के बारे में सोचें जो एक स्थिर वेब पेज प्रदर्शित करता है। मॉडल HTML है। दृश्य स्क्रीन पर वास्तविक परिणाम है।

अब कुछ जावास्क्रिप्ट जोड़ें। वह कंट्रोलर है। जब उपयोगकर्ता एक बटन पर क्लिक करता है या किसी चीज को खींचता है, तो ईवेंट जावास्क्रिप्ट में भेजा जाता है, तो यह तय करता है कि क्या करना है और अंतर्निहित HTML (मॉडल) को बदल देता है और ब्राउज़र / रेंडरर स्क्रीन पर उन परिवर्तनों को प्रदर्शित करता है (देखें)।

शायद एक और बटन पर क्लिक किया जाता है, घटना को कुछ हैंडलर (नियंत्रक) को भेजा जाता है, और यह आगे के डेटा के लिए एक webservice को भेजे जाने के लिए अनुरोध का कारण हो सकता है। परिणाम तब HTML (मॉडल) में जोड़ा जाता है।

नियंत्रक घटनाओं के प्रति प्रतिक्रिया करता है और मॉडल में जो कुछ है उसे नियंत्रित करता है और इसलिए स्क्रीन / देखें पर क्या है।

थोड़ा पीछे चलते हुए, आप पूरे ब्राउज़र को नियंत्रक के रूप में दृश्य और सर्वर के रूप में और मॉडल के रूप में डेटा के बारे में सोच सकते हैं। जब उपयोगकर्ता ब्राउज़र में एक बटन क्लिक करता है, तो इसे सर्वर (कंट्रोलर) को भेजे जाने वाले ईवेंट, यह HTML पेज (मॉडल) के रूप में एक साथ संसाधन इकट्ठा करता है और प्रदर्शित होने के लिए ब्राउज़र पर वापस भेजता है (देखें)

सर्वर में नीचे है कि क्या यह एस्प, php, या जावा है 'कोड' (नियंत्रक) क्लिक इवेंट प्राप्त करता है और एक डेटाबेस या दस्तावेज़ रिपॉजिटरी (मॉडल) से पूछताछ करता है और HTML बनाता है। सर्वर के दृष्टिकोण से इसकी सभी क्रियाओं का परिणाम इसके अंतर्निहित डेटास्टोर (मॉडल) का एक दृश्य (HTML) है। लेकिन क्लाइंट के दृष्टिकोण से सर्वर के लिए इसके अनुरोध का परिणाम इसका मॉडल (HTML) है

यहां तक ​​कि अगर आप अपने HTML में अपने जावास्क्रिप्ट या अपने HTML में अपने PHP के मॉडल, दृश्य, नियंत्रक अभी भी मौजूद है। यहां तक ​​कि अगर आप एक सर्वर के लिए अपने अनुरोध के बारे में सोचते हैं और सर्वर से प्रतिक्रिया दो सरल सड़क के रूप में, अभी भी एक मॉडल, एक दृश्य और एक नियंत्रक है।


-2

मेरे अनुभव में, एक पारंपरिक डेस्कटॉप mvc gui कार्यक्रम में, नियंत्रक को दृश्य में स्पैगेटिड समाप्त होता है। अधिकांश लोग एक नियंत्रक वर्ग को बाहर करने के लिए समय नहीं लेते हैं।

गिरोह के चार पुस्तक कहते हैं:

स्मॉलटाकल एमवीसी में डिजाइन पैटर्न

मॉडल / व्यू / कंट्रोलर (MVC) वर्गों का त्रय [KP88] का उपयोग स्मॉलटाकल -80 में उपयोगकर्ता इंटरफेस बनाने के लिए किया जाता है। MVC के अंदर के डिज़ाइन पैटर्न को देखकर आपको यह देखने में मदद करनी चाहिए कि हम "पैटर्न" शब्द का क्या मतलब है।

एमवीसी में तीन तरह की वस्तुएं होती हैं। मॉडल एप्लिकेशन ऑब्जेक्ट है, दृश्य इसकी स्क्रीन प्रस्तुति है, और नियंत्रक उपयोगकर्ता के इनपुट के उपयोगकर्ता के प्रतिक्रिया के तरीके को परिभाषित करता है। MVC से पहले, यूजर इंटरफेस डिजाइन इन वस्तुओं को एक साथ गांठ करने के लिए जाता है। एमवीसी उन्हें लचीलापन बढ़ाने और पुन: उपयोग करने के लिए decouples।

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

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

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

MVC की एक और विशेषता यह है कि विचारों को नेस्टेड किया जा सकता है। उदाहरण के लिए, बटन के एक नियंत्रण कक्ष को नेस्टेड बटन दृश्यों वाले एक जटिल दृश्य के रूप में लागू किया जा सकता है। ऑब्जेक्ट इंस्पेक्टर के लिए यूजर इंटरफेस में नेस्टेड विचार शामिल हो सकते हैं जिन्हें डीबगर में पुन: उपयोग किया जा सकता है। MVC समग्र दृश्य वर्ग, दृश्य उपवर्ग के साथ नेस्टेड दृश्यों का समर्थन करता है। सम्मिश्र दृश्य वस्तुओं की तरह काम करते हैं; जहाँ भी दृश्य का उपयोग किया जा सकता है, वहाँ एक समग्र दृश्य का उपयोग किया जा सकता है, लेकिन इसमें निहित विचार भी होते हैं और प्रबंधित होते हैं।

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

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

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

व्यू-कंट्रोलर संबंध रणनीति (315) डिज़ाइन पैटर्न का एक उदाहरण है। एक रणनीति एक वस्तु है जो एक एल्गोरिथ्म का प्रतिनिधित्व करती है। यह तब उपयोगी होता है जब आप एल्गोरिथ्म को या तो वैधानिक रूप से या गतिशील रूप से बदलना चाहते हैं, जब आपके पास एल्गोरिथ्म के बहुत से रूप होते हैं, या जब एल्गोरिथ्म में जटिल डेटा संरचनाएं होती हैं, जिन्हें आप एनकैप्सुलेट करना चाहते हैं।

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


1
ऐसा लगता है कि इस पूरे पोस्ट माइनस में पहले दो पैराग्राफ को डिज़ाइन पैटर्न से शब्दशः लिया गया है । मैंने उस खंड को एक उद्धरण के रूप में स्वरूपित किया है ताकि पाठकों को यह समझ में आए कि - कृपया संपादित करें यदि मैंने अनुच्छेदों को उद्धृत किया है जो आपके अपने हैं।
कालेब

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

यदि आप सहमत हैं कि यह एमवीसी की "उचित" व्याख्या है तो एमवीसी बिल्कुल कुछ नहीं खरीदता है। यह केवल एमवी हो सकता है और सी को छोड़ सकता है क्योंकि हर बार जब आप एक नया दृश्य बनाते हैं तो आपको एक नया नियंत्रक बनाने की भी आवश्यकता होती है। तो चिंताओं को अलग करने के सैद्धांतिक कारणों के अलावा उन्हें अलग करने के लिए दर्द लेने का क्या मतलब है।
डंक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.