क्या MVC सिर्फ PHP प्रोग्रामिंग का एसईओ है?


9

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

मूल एमवीसी अवधारणा को जीयूआई अनुप्रयोगों पर लक्षित किया गया था। और Gtk / Python के लिए इसके अनुसार इसका पालन करना संभव है। लेकिन PHP वेब ऐप लाइव व्यूज़ (GUI एलिमेंट्स) और लगातार कंट्रोलर रनटाइम पर काम नहीं करते हैं। यह निश्चित रूप से एक मिथ्या नाम है अगर यह सिर्फ इस्तेमाल किया कोड + निर्देशिका समूह या नामकरण का वर्णन करता है।

"MVC" PHP चौखटे के लिए एक चर्चा की तरह इस्तेमाल किया जा रहा है। और मैंने वास्तव में एक या दो परिपक्व PHP फ्रेमवर्क को देखा है, लेकिन इंटर्न से मिलान करने के लिए वैसे भी वाक्यांश को फिर से परिभाषित करना।
तो क्या यह आम तौर पर साँप का तेल है? बेहतर शब्दावली का उपयोग क्यों नहीं किया जाता है, और बनाए रखने योग्य PHP के लिए एक अधिक समझदार अवधारणा का प्रचार किया जाता है?

कुछ विस्तृत तर्क

मुझे संदेह है कि PHP कार्यान्वयन वास्तविक MVC पैटर्न का पालन नहीं करता है:

मॉडल : सिद्धांत रूप में, मॉडल मोटा होना चाहिए और इसमें व्यावसायिक तर्क शामिल होने चाहिए, और नियंत्रकों को पतले हैंडलर (इनपुट-> आउटपुट) होने चाहिए। वास्तव में PHP चौखटे उथले मॉडल की वकालत करती है । उदाहरण के लिए CI और सिम्फनी समान मॉडल == ORM। यहां तक ​​कि HTTP इनपुट नियंत्रक द्वारा नियंत्रित किया जाता है, मॉडल के रूप में नहीं माना जाता है।

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

नियंत्रक : मैं अनिश्चित हूँ। नियंत्रकों को संभवतः एमवीसी मॉडल में लंबे समय तक चलने और लगातार सक्रिय रहने की आवश्यकता नहीं है। PHP फ्रेमवर्क संदर्भ में, वे हालांकि ज्यादातर हैंडलर का अनुरोध करते हैं। नहीं वास्तव में कुछ के बारे में बहस करने के लिए, लेकिन यह सिर्फ थोड़ा buzzwordish लगता है।

क्या बेहतर वर्णनकर्ता होंगे? मैंने पीएमवीसी या एचएमवीसी जैसे समनुक्रमों को देखा है। हालाँकि वर्णन अधिक अस्पष्ट हैं, लेकिन शायद ये वर्तमान वेब फ्रेमवर्क को कम खोखला बताते हैं?


तो, निष्कर्ष में: PHP फ्रेमवर्क मूल MVC के समान एक अवधारणा को लागू करते हैं । मुझे लगता है कि यह यहाँ सबसे अच्छा है: stackoverflow.com/questions/1549857/simple-php-mvc-framework/…
mario

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

मॉडल (नहीं बहुवचन) एक है परत । यह एक एकल फ़ाइल या वर्ग नहीं है। यह डोमेन ऑब्जेक्ट्स, डेटा मैपर्स और सेवाओं का एक संग्रह है। पढ़ें यह
जेम्स

3
... एसईओ? "खोज इंजिन अनुकूलन"?
इज़्काता

जवाबों:


12

मुझे लगता है कि आप इसे पूरी तरह से गलत तरीके से देख रहे हैं। एक GUI ऐप और एक वेब पेज की दुनिया अलग है इसलिए MVC की सटीक समान परिभाषा दोनों के लिए कभी काम नहीं करेगी। MVC आदर्श के बारे में अधिक है: प्रदर्शन और तर्क जैसे ऐप के कुछ हिस्सों को अलग करना।

PHP में (या सामान्य रूप से वेब), एक दृश्य स्वयं वेब पेज है: HTML आउटपुट। यह आपकी परिभाषा के अनुसार "लाइव" नहीं है, लेकिन आप नियंत्रक (यानी एक अन्य पेज अनुरोध) पर वापस जाने के लिए लिंक पर क्लिक करते हैं।

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

तो "मॉडल-व्यू-कंट्रोलर" नाम पूरी तरह से तार्किक है, जो GUI ऐप्स बनाम वेब ऐप्स में एक अलग कार्यान्वयन है।


एमवीसी की अमूर्त अवधारणा के साथ मेरा कोई झगड़ा नहीं है। यह मेरी आपत्ति है कि PHP फ्रेमवर्क वास्तव में सिर्फ पैसिव-एमवीसी को लागू करने के बारे में बेईमान हैं। यहां तक ​​कि "मॉडल-व्यू-प्रस्तुतकर्ता" पैटर्न एक अधिक यथार्थवादी विवरण है। लेकिन निश्चित रूप से, जब आप उन्हें किसी अन्य डोमेन पर लागू करते हैं, तो शर्तों को संशोधित किया जाना चाहिए। मूल प्रश्न; झुकने शब्द यह एक चर्चा कर सकता है?
mario

3

जैसा कि मैं PHP फ्रेमवर्क से अनजान हूं, यह एक निम्न-स्तरीय भाषा के दृष्टिकोण से देखा जाता है।

मॉडल:

सिद्धांत रूप में, मॉडल मोटा होना चाहिए और व्यावसायिक तर्क होना चाहिए

यह पूरी तरह से करने के लिए है, मुझे नहीं पता है कि PHP को इसके साथ क्या करना है ...

मॉडल PHP में डेटा कक्षाएं हैं जो संभवतः डेटाबेस के साथ संवाद
कर सकते हैं , फिर आप क्लाइंट को JSON प्रारूप में एक ही मॉडल या एक आंशिक मॉडल भी भेज सकते हैं।

मैं व्यावसायिक तर्क नहीं कहूंगा, यह डेटा लॉजिक (सत्यापन, डेटाबेस इंटरैक्शन, आयात / निर्यात, ...) की तरह है।

और नियंत्रक पतले हैंडलर होने चाहिए (इनपुट-> आउटपुट)

आपके नियंत्रक वर्ग मॉडल कक्षाओं के साथ बातचीत करते हैं, वे वास्तव में पतले हैं।

आउटपुट के आधार पर, मॉडल के साथ कुछ चीजें करें ... और क्लाइंट को एक मॉडल व्यू लौटाएं ...

वास्तव में PHP चौखटे उथले मॉडल की वकालत करती है। उदाहरण के लिए CI और सिम्फनी समान मॉडल == ORM। यहां तक ​​कि HTTP इनपुट नियंत्रक द्वारा नियंत्रित किया जाता है, मॉडल के रूप में नहीं माना जाता है।

मैं वास्तव में उन PHP चौखटे के बारे में पता नहीं कर रहा हूँ ...

लेकिन कंट्रोलर तक पहुँचने से पहले HTTP इनपुट को संभालना चाहिए,
आप आसानी से एक क्लास बना सकते हैं जो GET और POST डेटा को अच्छे रूटिंग और पैरामीटर में बदल देता है।

ASP.NET MVC 2 में ऐसा ही होता है और इसमें कुछ भी गलत नहीं है,
मुझे नहीं पता कि PHP के साथ ऐसा कैसे होगा लेकिन मुझे लगता है कि यह निकटता से संबंधित होगा।

आप आसानी से GET और POST डेटा को एक मॉडल में बदल सकते हैं, हो सकता है कि मॉडल में इसके लिए कंस्ट्रक्टर लॉजिक हो। या उस उद्देश्य के लिए कुछ अलग कक्षाएं जोड़ी जा सकती हैं।


दृश्य:

AJAX के साथ वर्कअराउंड छूट दी गई है, वेब पृष्ठों पर दृश्य नहीं हो सकते। PHP फ्रेमवर्क अभी भी पेजों को पंप करता है।

मैं नहीं देख सकता कि यह क्यों नहीं हो सका, केवल अंतर प्रोटोकॉल और पीएचपी जेएसएन आदि को वापस कर सकता है ...

एक पृष्ठ आपका विचार है और यह AJAX + JSON के माध्यम से अनुरोध और अपडेट कर सकता है।
फिर, मैं वास्तव में उन PHP फ्रेमवर्क के बारे में नहीं जानता, लेकिन ASP.NET MVC 2 में यह उस तरह से काम करता है।

इंटरफ़ेस अभी भी प्रभावी रूप से साधारण HTTP मॉडल का अनुसरण करता है, गैर-एमवीसी अनुप्रयोगों पर कोई लाभ नहीं है। (और अंत में, व्यापक php चौखटे में से कोई भी तथ्यात्मक रूप से HTML के बजाय GUI दृश्य में आउटपुट कर सकता है। मैंने एक PHP लाइब्रेरी देखी है जो Gtk / Console / Web को संचालित कर सकती है, लेकिन चौखटे नहीं।)

एकमात्र लाभ जो आपको मिलता है (और सामान्य अनुप्रयोगों के साथ भी ऐसा ही है) मॉडल (डेटा) + व्यू (GUI) + नियंत्रक (तर्क) में पृथक्करण है। इसी तरह, आप एक C ++ फ्रेमवर्क नहीं देखेंगे, जो GUI व्यूज़ के बजाय HTML या JSON को वास्तव में आउटपुट कर सकता है।


नियंत्रक:

मैं अनिश्चित हूँ। नियंत्रकों को संभवतः एमवीसी मॉडल में लंबे समय तक चलने और लगातार सक्रिय रहने की आवश्यकता नहीं है। PHP फ्रेमवर्क संदर्भ में, वे हालांकि ज्यादातर हैंडलर का अनुरोध करते हैं। नहीं वास्तव में कुछ के बारे में बहस करने के लिए, लेकिन यह सिर्फ थोड़ा buzzwordish लगता है।

MVC एक सॉफ्टवेयर आर्किटेक्चर / पैटर्न है, जहां कंट्रोलर चलता है और कितने समय के लिए मैटर नहीं करता है।


1

लेकिन PHP वेब ऐप लाइव व्यूज़ (GUI एलिमेंट्स) और लगातार कंट्रोलर रनटाइम पर काम नहीं करते हैं।

नहीं, उन्हें यकीन है!

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

नियंत्रक भी लगातार है क्योंकि आप कुकीज़ / सत्र का उपयोग कर सकते हैं।

"MVC" PHP चौखटे के लिए एक buzzword की तरह इस्तेमाल किया जा रहा है।

MVC एक सॉफ्टवेयर आर्किटेक्चर है, कुछ फ्रेमवर्क इसे बज़ के रूप में उपयोग कर सकते हैं, लेकिन अन्य इसे ठीक से करते हैं ... विकिपीडिया पर कुछ फ़्रेमवर्क की सूची
देखें ।

क्या MVC सिर्फ php प्रोग्रामिंग का SEO है?

MVC और SEO दो चीजें अलग हैं, लेकिन हाँ ... MVC अधिक लोकप्रिय हो रहा है।


1
यकीन है, AJAX UI तत्व इसे करीब लाते हैं, लेकिन यह वास्तव में एक वैकल्पिक हल है। और यह अभी भी परिभाषा झुकने लगता है। (Btw, मैं Cappucino.org और अन्य वास्तविक टूलकिट से अवगत हूं, लेकिन PHP फ्रेमवर्क के सकल के लिए रेफरी कर रहा था।)
mario

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

1
मुझे पता है तुम्हारा क्या मतलब है। यदि आप PHP को एप्लिकेशन सर्वर और AJAX के रूप में तर्क और UI के बीच RPC तंत्र के रूप में व्याख्या करते हैं, तो हाँ। मैं फिर भी इसे HTTP पर वर्कअराउंड कहूंगा। OTOH सुनिश्चित नहीं है कि यह MVC संप्रदाय के लिए प्रासंगिक है। मुझे लगता है कि मैं वास्तव में इस निहितार्थ पर आपत्ति कर रहा हूं कि केवल "" "एमवीसी" "आपके द्वारा वर्णित उत्तरदायी और इंटरैक्टिव वेब यूआई प्रदान करता है।
मारियो

-1

मेरी राय में php में MVC का उपयोग प्रोग्रामर को वेब पर लाता है। जब आप MVC के साथ काम करना जानते हैं तो उदाहरण के लिए जावा से PHP तक जाना आसान है।


+1 लेकिन क्या यह सिर्फ एक शब्दावली का लाभ है, या PHP फ्रेमवर्क हैं जो जावा कार्यान्वयन के करीब हैं। (और स्पष्ट रूप से, आप जावा GUIs या वेब / स्ट्रट्स के बारे में बात कर रहे हैं?)
mario

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