"MVC" में "नियंत्रक" क्या जाता है?


186

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

उदाहरण के लिए कहते हैं कि मेरे पास काफी सरल अनुप्रयोग है (मैं विशेष रूप से जावा सोच रहा हूं, लेकिन मुझे लगता है कि वही सिद्धांत कहीं और लागू होते हैं)। मैं अपने कोड को 3 पैकेजों में व्यवस्थित करता हूं app.model, app.viewऔर app.controller

app.modelपैकेज के भीतर , मेरे पास कुछ कक्षाएं हैं जो एप्लिकेशन के वास्तविक व्यवहार को दर्शाती हैं। ये extends Observableऔर उपयोग setChanged()और notifyObservers()जब उचित अद्यतन करने के लिए विचारों को गति प्रदान करने।

app.viewपैकेज एक वर्ग (या प्रदर्शन के विभिन्न प्रकार के कई वर्गों) का उपयोग करता है javax.swingप्रदर्शन को संभालने के लिए घटकों। इन घटकों में से कुछ को मॉडल में वापस फीड करने की आवश्यकता है। अगर मैं सही तरीके से समझूं, तो प्रतिक्रिया के साथ देखने के लिए कुछ भी नहीं होना चाहिए - जिसे नियंत्रक द्वारा निपटाया जाना चाहिए।

तो मैं वास्तव में कंट्रोलर में क्या डालूं? क्या मैं public void actionPerformed(ActionEvent e)नियंत्रक में एक विधि के लिए एक कॉल के साथ दृश्य में डाल सकता हूं ? यदि हां, तो क्या किसी भी सत्यापन आदि को नियंत्रक में किया जाना चाहिए? यदि ऐसा है, तो मैं व्यू पर वापस त्रुटि संदेश कैसे दे सकता हूं - क्या यह फिर से मॉडल के माध्यम से जाना चाहिए, या नियंत्रक को इसे सीधे देखने के लिए वापस भेजना चाहिए?

यदि दृश्य में सत्यापन किया जाता है, तो मैं नियंत्रक में क्या डाल सकता हूं?

लंबे प्रश्न के लिए क्षमा करें, मैं सिर्फ इस प्रक्रिया की अपनी समझ का दस्तावेज बनाना चाहता था और उम्मीद है कि कोई मेरे लिए इस मुद्दे को स्पष्ट कर सकता है!

जवाबों:


519

आपके द्वारा सुझाए गए उदाहरण में, आप सही कह रहे हैं: "उपयोगकर्ता ने इंटरफ़ेस में 'इस आइटम को हटाएं' बटन पर क्लिक किया है, मूल रूप से नियंत्रक के" हटाएं "फ़ंक्शन को कॉल करना चाहिए। हालाँकि, नियंत्रक को यह पता नहीं है कि दृश्य कैसा दिखता है, और इसलिए आपके विचार में कुछ जानकारी एकत्र करनी चाहिए जैसे कि, "कौन सा आइटम आउट किया गया?"

बातचीत के रूप में:

देखें : "अरे, नियंत्रक, उपयोगकर्ता ने मुझे सिर्फ यह बताया कि वह आइटम 4 हटाना चाहता है।"
नियंत्रक : "हम्म, अपने क्रेडेंशियल्स की जाँच करने के बाद, उसे ऐसा करने की अनुमति है ... अरे, मॉडल, मैं चाहता हूं कि आप आइटम 4 प्राप्त करें और इसे हटाने के लिए आप जो कुछ भी करें।"
मॉडल : "आइटम 4 ... मिल गया। इसे हटा दिया गया है। आपके पास, नियंत्रक।"
नियंत्रक : "यहाँ, मैं डेटा के नए सेट को इकट्ठा करूँगा। आप पर वापस जाएँ, देखें।"
देखें : "कूल, मैं अब उपयोगकर्ता को नया सेट दिखाऊंगा।"

उस अनुभाग के अंत में, आपके पास एक विकल्प होता है: या तो दृश्य एक अलग अनुरोध कर सकता है, "मुझे सबसे हाल का डेटा सेट दें", और इस प्रकार अधिक शुद्ध हो, या नियंत्रक स्पष्ट रूप से "हटाएं" के साथ नया डेटा सेट लौटाता है " ऑपरेशन।


90
यह संवाद एमवीसी का सबसे अच्छा स्पष्टीकरण है, जो मुझे आया है, धन्यवाद!
पॉल वॉकर

13
सब ठीक है, लेकिन सीधे मॉडल से पढ़ने के दृश्य में कुछ भी गलत नहीं है । "कंट्रोलर डेटा पुलिस नहीं हैं"। एक सिद्धांत भी है जो नियंत्रकों को पतला रखने के लिए कहता है। व्यू हेल्पर्स आपके विचार से खपत होने के लिए तैयार डेटा एकत्र करने के लिए एक आदर्श स्थान है। कुछ डेटा-एक्सेस लॉजिक का पुन: उपयोग करने के लिए पूर्ण नियंत्रक स्टैक को डिस्पैच नहीं करना चाहिए। अधिक विवरण: rmauger.co.uk/2009/03/…
अपवाद

1
मैं "अपवाद ई" से सहमत हूं। मॉडल में डेटा को कई घटनाओं द्वारा अद्यतन किया जा सकता है, जरूरी नहीं कि नियंत्रक हो, और इसलिए कुछ एमवीसी में एम को वी संकेत देता है कि डेटा गंदा है और वी खुद को ताज़ा कर सकता है। उस मामले में C की कोई भूमिका नहीं है।
मिश्र

68

इसके साथ समस्या MVCयह है कि लोगों को लगता है कि नियंत्रक, और मॉडल को एक-दूसरे से जितना संभव हो उतना स्वतंत्र होना चाहिए। वे ऐसा नहीं करते हैं - एक दृश्य और नियंत्रक अक्सर intertwined होते हैं - इस बारे में सोचें M(VC)

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

मॉडल के रूप में एक मोहरबंद बॉक्स में एक पता लगाने के क्षेत्र में एक रेडियो-नियंत्रित रोबोट के बारे में सोचो।

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

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

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

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

क्या मैंने आपके प्रश्न का उत्तर दिया है? :-)

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

... क्या कोई सत्यापन आदि नियंत्रक में किया जाना चाहिए? यदि ऐसा है, तो मैं व्यू पर वापस त्रुटि संदेश कैसे दे सकता हूं - क्या यह फिर से मॉडल के माध्यम से जाना चाहिए, या नियंत्रक को इसे सीधे देखने के लिए वापस भेजना चाहिए?

यदि दृश्य में सत्यापन किया जाता है, तो मैं नियंत्रक में क्या डाल सकता हूं?

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

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

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

अन्य विचार तो है इन त्रुटियों के बारे में पता करने की जरूरत है, तो आप को प्रभावी ढंग से कह रहे हैं कि उपयोगकर्ता से इनपुट और किसी भी जिसके परिणामस्वरूप त्रुटियाँ हैं मॉडल के भाग और पूरी बात एक छोटे से अधिक जटिल है ...


23

यहाँ एमवीसी की मूल बातें पर एक अच्छा लेख है

य़ह कहता है ...

नियंत्रक - नियंत्रक मॉडल द्वारा किए जाने वाले कार्यों में दृश्य के साथ बातचीत का अनुवाद करता है।

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

Fowler पर एक और अच्छा लेख है


MVP एक अन्य विकल्प है जिसे आप संदर्भ के लेख में चर्चा करते हैं, देखें martinfowler.com/eaaev/ModelViewPresenter.html
जॉन

लिंक के लिए धन्यवाद, वे निश्चित रूप से दिलचस्प पढ़ने के लिए बनाते हैं।
पॉल वॉकर

18

एमवीसी पैटर्न आपको केवल व्यावसायिक तर्क (= मॉडल) से प्रस्तुति (= दृश्य) को अलग करना चाहता है । नियंत्रक भाग केवल भ्रम पैदा करने के लिए है।


1
वास्तव में, जो मैंने अब तक सोचा था, लेकिन कभी किसी को बताने की हिम्मत नहीं हुई .... या उचित शब्दों के साथ नहीं आ सकता है।
user1451111

1
मॉडल-व्यू-भ्रम
बारिश हो रही

10

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

व्यक्तिगत रूप से, पूर्ण विकसित एमवीसी कारखाने के डिजाइन पैटर्न की तरह लगता है कि यह आसानी से भ्रमित और अधिक जटिल डिजाइन की ओर जाता है। एक वास्तुकला अंतरिक्ष यात्री मत बनो ।


9

आपके प्रश्न के आधार पर, मुझे यह आभास होता है कि आप मॉडल की भूमिका पर थोड़े सहज हैं। मॉडल को एप्लिकेशन से जुड़े डेटा पर ठीक किया जाता है; यदि ऐप में डेटाबेस है, तो मॉडल का काम उससे बात करना होगा। यह उस डेटा से जुड़े किसी भी साधारण तर्क को भी हैंडल करेगा; यदि आपके पास एक नियम है जो कहता है कि सभी मामलों के लिए जहां TABLE.foo == "हुर्रे!" और TABLE.bar == "हुज़ाह!" उसके बाद TABLE.field = "W00t!" सेट करें, फिर आप चाहते हैं कि मॉडल इसकी देखभाल करे।

नियंत्रक वह है जो आवेदन के व्यवहार के थोक को संभालना चाहिए। तो आपके सवालों का जवाब देने के लिए:

क्या मैं सार्वजनिक शून्य कार्रवाई डाल सकता हूं (नियंत्रक ए) एक्शन को व्यू में कंट्रोलर में एक विधि के लिए कॉल के साथ?

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

यदि हां, तो क्या किसी भी सत्यापन आदि को नियंत्रक में किया जाना चाहिए?

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

यदि ऐसा है, तो मैं व्यू पर वापस त्रुटि संदेश कैसे दे सकता हूं - क्या यह फिर से मॉडल के माध्यम से जाना चाहिए, या नियंत्रक को इसे सीधे देखने के लिए वापस भेजना चाहिए?

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

मेरे अनुभव में, मॉडल और दृश्य के बीच सीधा संचार बहुत सीमित होना चाहिए, और दृश्य को मॉडल के किसी भी डेटा को सीधे बदलना नहीं चाहिए; यह नियंत्रक का काम होना चाहिए।

यदि दृश्य में सत्यापन किया जाता है, तो मैं नियंत्रक में क्या डाल सकता हूं?

ऊपर देखो; वास्तविक सत्यापन नियंत्रक में होना चाहिए। और उम्मीद है कि आपके पास अभी तक नियंत्रक में रखे जाने वाले कुछ विचार हैं। :-)

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


7

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

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

सेवा-उन्मुख: यही वह जगह है जहाँ काम किया जाता है।


3

नियंत्रक मुख्य रूप से दृश्य और मॉडल के बीच समन्वय के लिए है।

दुर्भाग्य से, यह कभी-कभी दृश्य के साथ मिल कर समाप्त हो जाता है - छोटे ऐप्स में हालांकि यह बहुत बुरा नहीं है।

मेरा सुझाव है:

public void actionPerformed(ActionEvent e)

नियंत्रक में। तब आपके विचार में आपके एक्शन श्रोता को नियंत्रक को सौंपना चाहिए।

सत्यापन भाग के लिए, आप इसे दृश्य या नियंत्रक में रख सकते हैं, मुझे व्यक्तिगत रूप से लगता है कि यह नियंत्रक में है।

मैं निश्चित रूप से पैसिव व्यू और सुपरवाइजिंग प्रस्तोता पर एक नज़र डालने की सिफारिश करूँगा (जो अनिवार्य रूप से मॉडल व्यू प्रस्तोता में विभाजित है - कम से कम फाउलर द्वारा)। देख:

http://www.martinfowler.com/eaaDev/PassiveScreen.html

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html


3

यहां अंगूठे का एक नियम है जो मैं उपयोग करता हूं: यदि यह एक ऐसी प्रक्रिया है जिसका उपयोग मैं विशेष रूप से इस पृष्ठ पर कार्रवाई के लिए करूंगा , तो यह नियंत्रक में है, न कि मॉडल में। मॉडल को डेटा भंडारण के लिए केवल एक सुसंगत अमूर्त प्रदान करना चाहिए।

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


1

यह भी ध्यान दें कि प्रत्येक स्विंग विजेट को तीन MVC घटकों को शामिल करने के लिए माना जा सकता है: प्रत्येक में एक मॉडल (यानी ButtonModel), एक दृश्य (BasicButtonUI), और एक नियंत्रण (JButton स्वयं) है।


1

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

वैसे भी, एक उचित MVC कार्यान्वयन में केवल निम्न इंटरैक्शन होंगे: मॉडल -> दृश्य देखें -> नियंत्रक नियंत्रक -> दृश्य

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


0

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


0

हम इसे मुख्य रूप से, उपयोगकर्ता द्वारा संचालित इनपुट / क्रियाओं को संभालने और प्रतिक्रिया करने के लिए मुख्य रूप से नियंत्रकों का उपयोग करते हैं (और दृश्य, डेटा और स्पष्ट _Model सामान को छोड़कर, बाकी सब के लिए _Logic):

(1) (प्रतिक्रिया, प्रतिक्रिया - उपयोगकर्ता के जवाब में व्हाट्सएप "क्या करता है") Blog_Controller

-> मुख्य ()

-> handleSubmit_AddNewCustomer ()

-> verifyUser_HasProperAuth ()

(2) ("व्यवसाय" तर्क, क्या और कैसे वेबैप "सोचता है") Blog_Logic

-> sanityCheck_AddNewCustomer ()

-> handleUsernameChange ()

-> sendEmail_NotifyRequestedUpdate ()

(3) (विचार, पोर्टल, वेबैप "कैसे प्रकट होता है") Blog_View

-> genWelcome ()

-> genForm_AddNewBlogEntry ()

-> genPage_DataEntryForm ()

(4) (डेटा ऑब्जेक्ट केवल, प्रत्येक ब्लॉग के _ निर्माण () में प्राप्त किया गया * वर्ग के सभी ऑब्जेक्ट्स को एक ऑब्जेक्ट के रूप में एक साथ रखने के लिए उपयोग किया जाता है) Blog_Meta

(5) (मूल डेटा परत, DBs को पढ़ता / लिखता है) Blog_Model

-> saveDataToMemcache ()

-> saveDataToMongo ()

-> saveDataToSql ()

-> loadData ()

कभी-कभी हम इस बात पर थोड़ा भ्रमित हो जाते हैं कि सी या एल में कोई विधि कहाँ रखी जाए, लेकिन मॉडल रॉक सॉलिड, क्रिस्टल क्लियर है, और चूंकि सभी-इन-मेमोरी डेटा _Meta में रहते हैं, इसलिए यह एक बिना दिमाग वाला है। । हमारा सबसे बड़ा लीप फॉरवर्ड _Meta उपयोग को अपना रहा था, क्योंकि इसने विभिन्न _C, _L और _Model ऑब्जेक्ट्स से सभी क्रूड को साफ कर दिया था, यह सब मानसिक रूप से प्रबंधित करने में आसान बना दिया, साथ ही, एक बार फिर से, इसने हमें वह दिया जो कि हो रहा है "डिपेंडेंसी इंजेक्शन" कहा जाता है, या सभी डेटा (जिसका बोनस "परीक्षण" पर्यावरण का आसान निर्माण है) के साथ-साथ पूरे वातावरण में गुजरने का एक तरीका है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.