क्या नियंत्रक को दृश्य और मॉडल के बारे में पता होना चाहिए? या ठीक इसके विपरीत?

Question

मैं वैचारिक रूप से यह समझने की कोशिश कर रहा हूं कि क्या मुझे ऐसा करना चाहिए:

item = Model()
screen = View()
brain = Controller(item, screen)

या यह..

brain = Controller()
item = Model(brain)
screen = View(brain)

या यह..

class Controller():
    def __init__(self):
        item = Model(self)
        screen = View(self)

या कुछ और पूरी तरह से?

Answer 1

मेरे लिए, पहला विकल्प समझ में आता है। नियंत्रक का काम दृश्य और मॉडल के बीच समन्वय करना है। उस दृष्टिकोण से, यह नियंत्रक के लिए समझ में आता है कि वह दृश्य और मॉडल के संदर्भों को नियंत्रित करता है।

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

Answer 2

Modelऔर Viewएक दूसरे से स्वतंत्र हैं।

MVC संरचना Controllerके दिमाग के रूप में मत सोचो । इसे डिस्पैचर के रूप में सोचें जो ब्राउज़र से अनुरोधों को संभालता है, और उन्हें डिस्पैच करता है Model। यह तब डेटा से लेता है Modelऔर इसे टेम्पलेट फ्रेंडली तरीके से पैकेज करता है , और फिर इसे एक को भेजता है View।

Modelहै दिमाग MVC संरचना में, और यह वह जगह है जहाँ आप अपने व्यापार के नियम रखना चाहिए। कई नियंत्रकों में व्यावसायिक नियम सामान्य हैं । तो एक दस्तावेज़ नियंत्रक, और एक रिपोर्ट नियंत्रक दोनों एक उपयोगकर्ता मॉडल का उपयोग करके यह देख सकते हैं कि उन चीजों तक पहुंच किसके पास है। आप उन नियमों को दोनों नियंत्रकों में दोहराना नहीं चाहेंगे।

Viewएक गैर डेटा स्रोत विशिष्ट तरीके से डेटा पेश करने के लिए एक HTML टेम्पलेट का उपयोग करना चाहिए। यह आपके डेटाबेस के स्कीमा के लिए कसकर बाध्य नहीं होना चाहिए। किसी दस्तावेज़ के शीर्षक को दिखाने के लिए आपके पास व्यू टेम्प्लेट चर की सामग्री को आउटपुट कहा जाता है document_title, और केवल यह Controllerजानता है कि उस चर को कैसे सेट किया गया था, और केवल यह Modelजानता है कि उस दस्तावेज़ का शीर्षक क्यों है।

Comments

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

— अल्नाफी

@alnafie आपने केवल 3 वर्गों में एक MVC फ्रेमवर्क को सरल बनाया है। मौजूदा MVC के ओपन सोर्स फ्रेमवर्क पर नज़र डालें, और आप पाएंगे कि इसे काम करने के लिए और भी बहुत कुछ आवश्यक है। कुछ उच्च होना चाहिए जो ढांचे के लिए सभी टुकड़ों का प्रबंधन करता है। कुछ जो कंट्रोलर्स को कॉल करता है, और कुछ ऐसा जो व्यूज में क्रियाओं को रूट करने का काम करता है।

— रिएक्टगुलर

Answer 3

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

वेब 1.0 अनुप्रयोगों (पूर्ण पृष्ठ ताज़ा, कोई AJAX) के लिए उपयोग की जाने वाली "MVC" वास्तुकला कुछ अलग है। एक नियंत्रक के लिए एक वेब अनुरोध भेजा जाता है। नियंत्रक किसी तरह मॉडल स्थिति को संशोधित करता है, फिर एक या अधिक मॉडल को एक दृश्य द्वारा प्रस्तुत करने के लिए भेजता है। नियंत्रक और दृश्य दोनों मॉडल पर निर्भर करते हैं, लेकिन नियंत्रक भी दृश्य पर निर्भर करता है।

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

Comments

+1 अच्छा जवाब। मैं क्लासिक अर्थों में डेस्कटॉप एप्लिकेशन के लिए मॉडल कॉलबैक को समझ सकता हूं। मुझे Microsoft से पुराने MFC की याद दिलाता है।

— रिएक्टगुलर

Answer 4

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

उपयोगकर्ता दिशा (उदाहरण के लिए पुट, माउस और मेन्यू कमांड में कीबोर्ड) के परिणामस्वरूप नियंत्रक को मॉडल में परिवर्तन को धक्का देना चाहिए।

मॉडल मॉडल और सदस्यता की सूची बनाए रखता है, और उन्हें अपने सदस्यता के माध्यम से लागू परिवर्तनों के विचारों को सूचित करना चाहिए।

नए विचारों और नियंत्रकों को बनाने के लिए एक तंत्र होने की भी आवश्यकता है (चूंकि एमवीसी में आपको एक ही मॉडल के दो या अधिक विचार करने में सक्षम होना चाहिए (वे एक ही दृश्य हो सकते हैं) (बिंदु) या अलग-अलग दृश्य (बिंदु)। तार्किक रूप से, हम विचार कर सकते हैं कि नियंत्रक को व्यू एंड कंट्रोलर (पेयर) फैक्ट्री में प्रदर्शन या पहुँच की आवश्यकता है, जो नियंत्रक या किसी अन्य घटक का हिस्सा हो सकता है।

Comments

-1 Modelsसूचित न करें Views। परिवर्तनों Controllersके Modelलिए क्वेरी करें , और फिर Viewsउन परिवर्तनों को प्रस्तुत करने के लिए प्रस्तुत करें।

— रिएक्टगुलर

एमवीसी में @ मैथ्यू फोसकारिनी, व्यू मॉडल से परिवर्तन की सदस्यता लेता है। उदाहरण के लिए, wiki.squeak.org/squeak/598 देखें ।

मुझे लगता है कि हम मौजूदा MVC फ्रेमवर्क में अंतर नहीं कर रहे हैं। Zend MVC, C # .NET और CakePHP मॉडल को व्यू से कनेक्ट न करें। उन चौखटों में एक दृश्य स्वतंत्र है। मुझे नहीं पता कि आपने किस MVC के साथ काम किया है, लेकिन मैं इसे गैर-पारंपरिक कहूंगा।

— रिएक्टगुलर

@ मैथ्यू फोसकारिनी: वे सभी वेब फ्रेमवर्क हैं, और भले ही वे खुद को "एमवीसी" कहते हैं, वे क्लासिक एमवीसी वास्तुकला का पालन नहीं कर रहे हैं।

— केविन क्लाइन

मुझे यकीन नहीं है कि स्मॉलटाक एमवीसी की तुलना में कोई भी एमवीसी अधिक "पारंपरिक" है, इसके साथ यह पहला था जहां पैटर्न का वर्णन किया गया था।

Answer 5

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

इसे स्वीकार करने के लिए, पैटर्न प्रत्येक MVC घटकों के कार्यान्वयन तर्क को अलग करना है। फिर भी, यह पूरी तरह से सामान्य है कि घटक जानते हैं कि एक दूसरे को इंटरफेस है ।

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