2012-11-05 15 views
14

मैं पैटर्न पैटर्न के लिए अपेक्षाकृत नया हूं लेकिन मुझे लगता है कि मुझे एमवीसी पैटर्न और कोड के इस अलगाव के फायदे की अच्छी समझ है।दृश्य दृश्य में एमवीसी में दृश्य को विभाजित क्यों करें और एक टेम्पलेट

हालांकि, दोनों बार मैं एक्शन (Magento और जूमला!) में MVC पैटर्न देखा है, वहाँ और एक PHP टेम्पलेट फ़ाइल दोनों एक दृश्य के वर्ग (Magento ब्लॉक) से मिलकर दृश्य के साथ आगे विशेषज्ञता है। अगर कोई इस विभाजन के लाभ की व्याख्या कर सकता है तो मैं इसकी सराहना करता हूं।

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

उत्तर

2

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

3

आप view को what और टेम्पलेट how के रूप में देख सकते हैं।

दृश्य मॉडल का उपयोग करके डेटा तैयार करता है और यह डेटा टेम्पलेट पर उपलब्ध कराता है।

बदले में, टेम्पलेट को आम तौर पर दृश्य के दायरे में (जूमला में, कम से कम) कहा जाता है।

यह पहली बार अनावश्यक प्रतीत हो सकता है, लेकिन टेम्पलेट का उपयोग करते समय इस दृष्टिकोण की शक्ति प्रकट होती है ओवरराइड करता है। फिर, दृश्य अकेला छोड़ा जा सकता है, और केवल इस टेम्पलेट के लिए टेम्पलेट (या उप-टेम्पलेट्स), ओवरराइड किया जा सकता है।

यहां तक ​​कि एक ही मुख्य (जूमला!) टेम्पलेट का उपयोग करते हुए, आप पैरामीटर के रूप में टेम्पलेट को पैरामीटर के रूप में निर्दिष्ट कर सकते हैं, यदि आपको प्रस्तुति के कुछ विशेषज्ञता की आवश्यकता है। यह कोड पुनरावृत्ति को भी हटा देता है।

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

+1

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

+0

मेरा संपादन पांच मिनट के नियम में खो गया है, बाकी के उपरोक्त पढ़ना चाहिए। जहां तक ​​मैं बता सकता हूं, जूमला का उपयोग करते समय! ऐसे तीन क्षेत्र हैं जो मॉडल से सामग्री को प्रस्तुत करने के तरीके को नियंत्रित करते हैं, ये हैं: 1) दृश्य 2) टेम्पलेट्स और 3) स्टाइल शीट्स। क्या आप एक उदाहरण प्रदान कर सकते हैं कि इन स्थानों के बीच प्रस्तुति को कैसे और क्यों विभाजित किया जाना चाहिए। – Dom

+0

आप सामग्री ओवरराइड के लिए एक स्पष्टीकरण पा सकते हैं, जो इस अलगाव के लिए सबसे आम उपयोग केस है, [यहां] (http://docs.joomla.org/Understanding_Output_Overrides)। यहां तक ​​कि आपके डिफ़ॉल्ट स्थापित टेम्पलेट्स में अंतर्निहित ओवरराइड भी हैं। दृश्य को कोड के सामान्य टुकड़े के रूप में उपयोग किया जाता है जो डेटा प्राप्त करता है और इसे चर में निर्दिष्ट करता है, फिर प्रतिपादन भाग को कॉल करता है, जो दृश्य का टेम्पलेट है (इसे जूमला में 'लेआउट' कहा जाता है)। एक छोटा सा स्पष्टीकरण पाया जा सकता है [यहां] (http://docs.joomla.org/How_to_override_the_output_from_the_Joomla!_core)। – MasterAM

0

यह http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html पढ़ें। मेरे लिए एमवीसी का अर्थ है कि उस सरणी के माध्यम से एक सरणी और लूप में फ़ंक्शन पंजीकृत करना और अंततः मुख्य प्रोग्राम में फ़ंक्शन को कॉल करना। लेकिन कई लोगों के लिए यह दृश्य (एचटीएमएल टेम्पलेट) और नियंत्रक (मुख्य अनुप्रयोग) से मॉडल (डेटाबेस) को अलग करना प्रतीत होता है। लेकिन ऐसा नहीं है जो मुझे लगता है कि एक कार्यक्रम के बारे में विशेष है। जब आप स्वाभाविक रूप से वेब एप्लिकेशन विकसित करते हैं तो आपके पास डेटाबेस, ब्राउज़र, बैकएंड और फ्रंटएंड, एचटीएमएल, सीएसएस, छवि फाइलों, वीडियो फाइलों और PHP भाषा आदि जैसे सभी बैकएंड होते हैं। इसे जटिल शब्दों में क्यों भ्रमित किया जाता है? मुझे लगता है कि एमवीसी सामान्य होना उपयोगी है। सजावट पैटर्न सीखें यह अधिक उपयोगी है।

0

ईमानदार होने के लिए ... प्रदर्शन के लिए सबसे अच्छा विकल्प बैकएंड में वेब सेवाएं बनाना और सर्वर से बात करने के लिए जावास्क्रिप्ट लाइब्रेरी का उपयोग करना है। जूमला और अन्य सीएमएस वितरण एमवीसी में इन दोनों डिजाइन पैटर्न को अमूर्त करने की कोशिश करते हैं जिससे एमवीसी और वेब सेवाओं/क्लाइंट-साइड कोड का संकर होता है। ऐसी हाइब्रिड प्रकृति जावास्क्रिप्ट परिदृश्य में एक्सटेंशन को विस्तारित करने की अनुमति देती है जो कि वेब की अगुआई वाली दिशा प्रतीत होती है।

+1

यह विचारों और टेम्पलेट्स को अलग करने से कैसे संबंधित है? –

6

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

आप कह सकते हैं कि शास्त्रीय MVC और MODEL2 MVC पैटर्न में, केवल देखने वाले मॉडल परत से पढ़ता है, लेकिन नियंत्रक केवल इसे करने के लिए लिखता है।

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

टेम्पलेट्स, आपके मूल वेब एप्लिकेशन में, टैग और PHP चर के मिश्रण के साथ बस साधारण फ़ाइलें हैं।

+1

दृश्य को मॉडल से डेटा का अनुरोध नहीं करना चाहिए। नियंत्रक मॉडल से डेटा का अनुरोध करता है और इसे देखने के लिए उपलब्ध कुछ (कुछ) बनाता है। दृश्य की ज़िम्मेदारी नियंत्रक –

+7

हाँ द्वारा खुलासा डेटा का उपयोग करके टेम्पलेट प्रस्तुत करना है, [केवल एमवीसी गोल्ड बैज] (http://stackoverflow.com/help/badges/3849/model- व्यू-कंट्रोलर) SO – Fabor

+1

@ मिहाईराडुकानु शायद [यह (थोड़ा नया) पोस्ट] (http://stackoverflow.com/a/16596704/727208) आपके दृष्टिकोण के पीछे तर्क को समझने में आपकी सहायता करेगा। –

संबंधित मुद्दे