मॉडल व्यू नियंत्रक की व्याख्या करें

Question

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

जब मुझे लगता है कि "गतिशील वेबसाइट", मुझे लगता है: उपयोगकर्ता एक क्वेरी स्ट्रिंग के साथ एक URL का अनुरोध करता है, सर्वर क्वेरी प्राप्त करता है, और फिर क्वेरी का जवाब देने के लिए गतिशील रूप से HTML आउटपुट करता है। इसमें डिस्प्ले के लिए अनुरोधित डेटा लाने के लिए अक्सर डेटाबेस के साथ संचार शामिल होता है। यह मूल रूप से doGetजावा की पद्धति के पीछे का विचार है HttpServlet।

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

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

Answer 1

पहले मुझे लगता है कि एमवीसी आर्किटेक्चर क्या है, इसके बारे में सबसे अच्छी बात है और फिर जिस तरह से आप वर्तमान में प्रोग्रामिंग कर रहे हैं उसमें और आगे बढ़ें।

MVC आर्किटेक्चर एक सोफ्टवेयर सिस्टेम के अंदर वर्कफ़्लो को व्यवस्थित करने का एक तरीका है, इसे व्यवहार को लागू करने के लिए एक स्तरित तरीके के रूप में सोचें। यह परतें हैं:

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

   मॉडल पहले लगता है कि आप बंद सोचना चाहिए क्योंकि है अपने अपने अनुप्रयोगों के केंद्र होने जा रहा ।

2. नियंत्रक : यह वह जगह है जहां जादू होता है और जहां स्तरित वास्तुकला ऑब्जेक्ट ओरिएंटेड प्रतिमान से मिलता है, इसका उपयोग करने का इरादा था। यहाँ है जहाँ आप कार्यान्वित करते हैं कि सिस्टम कैसे प्रतिक्रिया करता है जब कुछ एप्लिकेशन उपयोगकर्ता ऐप के बारे में उपयोगकर्ता इंटरफ़ेस से कुछ अनुरोध करते हैं।

   नियंत्रक को मॉडल ऑब्जेक्ट्स को संभालने में सक्षम होना चाहिए, उपयोगकर्ता द्वारा प्राप्त किए गए कार्यों को प्राप्त करने के लिए उनके साथ संचालन करें और फिर परिणाम को देखने के लिए संबंधित दृश्य परत को हमारे उपयोगकर्ता को सौंपने के लिए सौंप दें।

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

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

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

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

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

यहाँ एक क्यू एंड ए उदाहरण साइट है जो थोड़ा स्पष्ट करने के लिए एमवीसी आर्किटेक्चर का उपयोग कर रहा है

Answer 2

तुम्हारे प्रश्न का उत्तर देने के लिए

What does MVC offer over something like a Java servlet

एमवीसी एक पैटर्न है, न कि तकनीक। तो जब आप सर्वलेट्स के साथ भी प्रोग्रामिंग कर रहे हों तो पैटर्न लागू किया जा सकता है।

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

इस मामले में, MVC केवल व्यवसाय को प्रस्तुति परत और नियंत्रक परत से अलग करने के बारे में नहीं है, लेकिन व्यवसाय परत को यह भी पता नहीं है कि नियंत्रक या प्रस्तुति मौजूद है।

जावा में प्रमुख ढांचे जैसे स्ट्रट्स इस पैटर्न का पालन करते हैं। मुझे लगता है कि आपको अवधारणा गलत लगी। आप इंटरनेट में इसके बारे में अधिक पढ़ सकते हैं।

Answer 3

MVC वास्तव में समझने में आसान है, यह सिर्फ एक डिज़ाइन पैटर्न है, हालांकि, मैंने देखा है कि सबसे कठिन / ओवरसाइज़ मॉडल हिस्सा है।

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

Answer 4

मॉडल-व्यू-नियंत्रक अवधारणा कोई नई बात नहीं है। यह 1979 के आसपास स्मालटाक के साथ शुरू हुआ।

इसके मूल में, MVC आपके कोड की जिम्मेदारियों को व्यवस्थित करने का एक तरीका है, ताकि यह मॉड्यूलर, पूर्वानुमान और मजबूत हो।

अलगाव आपको निम्नलिखित स्वतंत्रता देता है:

• एप्लिकेशन लॉजिक को प्रभावित किए बिना या डेटा प्रदर्शित किए बिना मॉडल को विकसित करने की क्षमता
• मॉडल को प्रभावित किए बिना व्यावसायिक तर्क बदलने की क्षमता (यानी नए कदम जोड़ें, आदि)
• कई अलग-अलग तरीकों से मॉडल का प्रतिनिधित्व करने की क्षमता

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

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