मुझे MVC पैटर्न का उपयोग क्यों करना चाहिए?

Question

ऐसा लगता है कि हर कोई आजकल वेब एप्लिकेशन कर रहा है, हर चीज के लिए एमवीसी का उपयोग करना चाहता है। हालाँकि मुझे इस पैटर्न का उपयोग करने के लिए खुद को समझाना मुश्किल है। मैं समझता हूं कि सामान्य विचार कार्यक्रम के प्रतिनिधित्व वाले बैकएंड तर्क को अलग करना है। आमतौर पर, ऐसा लगता है कि विचार हमेशा कुछ हद तक नियंत्रक पर निर्भर करते हैं, जो मॉडल के आधार पर समाप्त होता है। मुझे नहीं लगता कि कंट्रोलर को जोड़ने से मुझे क्या फायदा होता है। मैंने बहुत सारे प्रचार के बारे में पढ़ा है "इस तरह से अनुप्रयोगों को डिज़ाइन किया जाना चाहिए", लेकिन शायद मुझे अभी भी समझ नहीं आया कि क्या जाना चाहिए। जब भी मैं MVC के बारे में दूसरों से बात करता हूं तो ऐसा लगता है कि हर किसी का विचार अलग है कि वह किस श्रेणी में है।

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

Comments

एमवीसी केवल सेपरेशन ऑफ कंसर्न का कार्यान्वयन है । कोई भी कार्यान्वयन करेगा।

— क्लेरेंस ऑफ़ सेन्सर

@ रेयानोस: शायद। लेकिन यह वह जगह नहीं है जहाँ "प्रचार" हो रहा है।

— बिली ओपल

प्रचार प्रचार वक्र का पालन करता है । इसे आप बहुत अधिक प्रभावित न करें। मेरे दृष्टिकोण से, MVC SoC के लिए एक ठोस वास्तुकला है और इसे लागू करना आसान है। मैं एक ठोस विकल्प के बारे में नहीं सोच सकता।

— रेयनोस

सबसे मौजूदा यूजर-इंटरफेस फ्रेमवर्क कसकर V और C को लिंक करते हैं और जब आप दूसरे पर स्विच करते हैं, तो आपको व्यू और कंट्रोलर (एम से इंटरफेस जो यूजर देखता है, दोनों को फिर से लिखना होगा)

— शाफ़्ट फ्रीक

लेकिन चिंताओं का पृथक्करण OO विकास की एक संपत्ति है। आपको चिंता कोड के एक अलग पृथक्करण को लागू करने के लिए एक MVW पैटर्न का उपयोग करने की आवश्यकता नहीं है?

— बस्तिन वंदामे १६'१४ को

Answer 1

हे। MVC के बारे में आपके भ्रम से मार्टिन फॉलर सहमत हैं:

मुझे MVC को एक पैटर्न के रूप में सोचने के लिए यह बहुत उपयोगी नहीं लगता क्योंकि इसमें काफी अलग विचार हैं। अलग-अलग जगहों पर एमवीसी के बारे में पढ़ने वाले अलग-अलग लोग इससे अलग-अलग विचार लेते हैं और इन्हें 'एमवीसी' के रूप में वर्णित करते हैं। यदि यह पर्याप्त भ्रम पैदा नहीं करता है तो आपको एमवीसी की गलतफहमी का प्रभाव मिलता है जो चीनी फुसफुसाते हुए सिस्टम के माध्यम से विकसित होता है।

हालांकि, वह MVC को और अधिक स्पष्ट व्याख्याओं में से एक देता है:

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

आप Fowler का पूरा लेख यहाँ पढ़ सकते हैं ।

Answer 2

मुझे लगता है कि आप जिस समस्या से निपट रहे हैं, उस पर बहुत कुछ निर्भर करता है। मैं अलगाव को निम्नानुसार देखता हूं:

मॉडल - हम डेटा का प्रतिनिधित्व कैसे करते हैं? उदाहरण के लिए, मैं अपनी वस्तुओं से लगातार स्टोरेज जैसे DB -> मैं डेटाबेस के लिए अपने 'उपयोगकर्ता' ऑब्जेक्ट को कैसे बचा सकता हूं?

नियंत्रक - मैं क्या कर रहा हूँ? यह वह क्रिया है जो वैचारिक स्तर पर होती है और क्या होती है, इसे अंजाम देने की जरूरत है। उदाहरण के लिए, उपयोगकर्ता को चालान करने के लिए मुझे किन चरणों से गुजरने की आवश्यकता है? एनबी यह किसी भी राशि की वस्तुओं को प्रभावित कर सकता है, लेकिन उन्हें डीबी के लिए कैसे जारी रखा जाता है, इसके बारे में कुछ भी नहीं पता है।

देखें - मैं परिणाम कैसे प्रस्तुत करूं?

जो समस्या मुझे महसूस हो रही है कि आप देख रहे हैं कि बहुत सारे वेब एप्लिकेशन एक DB के लिए एक शानदार CRUD (Create-Retrieve-Update-Delete) इंटरफ़ेस हैं। अर्थात नियंत्रक को 'एक उपयोगकर्ता जोड़ने' के लिए कहा जाता है, और यह तब मॉडल को 'उपयोगकर्ता जोड़ने' के लिए कहता है। कुछ भी हासिल नहीं हुआ।

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

Comments

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

— बिली ओपल

HTTP सामान के रूप में क्या मायने रखता है? मैं निम्नलिखित को एक नियंत्रक में शामिल करूंगा: HTTP अनमार्टहॉलिंग अनुरोधों को अस्वीकार करना, बुनियादी पवित्रता के मापदंडों की जांच करना, यह निर्धारित करना कि क्या करने की आवश्यकता है, उपयुक्त मॉडल ऑब्जेक्ट पर जाकर (पढ़ने, लिखने या दोनों के लिए), मॉडल की प्रतिक्रियाओं के आधार पर एक अंतिम परिणाम का उत्पादन करना। उस दृश्य से गुजर रहा है। कुछ के लिए एक मूर्खतापूर्ण उदाहरण केवल एक नियंत्रक के लिए इस्तेमाल किया जाएगा एक यादृच्छिक संख्या उत्पन्न करने वाली एक वेब सेवा हो सकती है - इस मामले में देखने के लिए कोई 'मॉडल' नहीं है (मेरे दिमाग में कम से कम ...)

— अनक सिप

वे सभी मॉडल चिंताएं हैं। यहां तक ​​कि "यह तय करने की आवश्यकता है कि क्या करना है" ("सामने नियंत्रक") एक मॉडल है।

— बिली ओपल

उल्लेख करने के लिए नियंत्रक आपके मॉडल को आपके विचारों के लिए कठिन-युग्मन नहीं करने के लिए उपयोगी हैं। साथ ही आपको एक नियंत्रक के माध्यम से कई मॉडलों से कई विचारों को जोड़ने की अनुमति देता है।

— रेयानोस

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

— मार्जन वेनमे

Answer 3

आपको नहीं करना चाहिए

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

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

दिन के अंत में, जो वास्तव में महत्वपूर्ण है वह तर्क से दृष्टिकोण को अलग करना है। कार्यान्वयन के संदर्भ में न केवल यह साफ है, बल्कि यह FE / BE इंजीनियरों को समानांतर में काम करने की अनुमति देता है (जब टीम के वातावरण में काम कर रहा होता है)।

(साइड नोट: मैं पेशेवर रूप से वेब ऐप विकसित नहीं करता हूं, इसलिए ऐसा कुछ हो सकता है जो मुझे याद आ रहा है)

Comments

मैं पूरी तरह से सहमत हूं, अच्छा जवाब। नियंत्रक हमेशा आवश्यक नहीं है, यह सिर्फ मॉडल के साथ संवाद करने के लिए एक रणनीति के रूप में है।

— फाल्कन

@ फाल्कन: देखिए, यह मेरा भ्रम है। मैंने एक से अधिक लोगों को यह कहते हुए देखा है कि दृश्य को नियंत्रक से बात नहीं करनी चाहिए; यह केवल मॉडल के लिए बात करनी चाहिए ...

— बिली ओपल

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

— डेमियन ब्रेख्त

@ डेमियन: मैंने रिवर्स सुना है (कि नियंत्रकों को प्रभावी रूप से कुछ भी नहीं करना चाहिए)। अक्सर। इस पैटर्न के साथ मेरी सबसे बड़ी समस्या है; कोई भी इस पर सहमत नहीं है कि यह क्या है।

— बिली ओपल

हां, मैंने अक्सर सुना है कि यदि आपको एक कमरे में 10 प्रोग्रामर मिलते हैं, तो आपको एमवीसी क्या है इसकी 9 अलग-अलग परिभाषा मिलेगी। वास्तव में, मुख्य बिंदु चिंताओं का अलगाव है। धार्मिक बहस के अलावा और क्या लगता है।

— डेमियन ब्रेख्त

Answer 4

हां, इस पर शब्दावली एक गड़बड़ है। इसके बारे में बात करना मुश्किल है क्योंकि आप कभी भी किसी के द्वारा शर्तों का मतलब नहीं समझते हैं।

जहाँ तक एक अलग नियंत्रक क्यों, कारण इस बात पर निर्भर हो सकता है कि आप नियंत्रक के किस संस्करण के बारे में बात कर रहे हैं।

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

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

Answer 5

सीधे शब्दों में कहें: चिंताओं को अलग करना। चीजों को करने के "सही" तरीके के बारे में सभी बातों के अलावा, क्लीनर कोड आदि, आप बस इतना कह सकते हैं कि एमवीसी आपको अपने कोड का अधिक आसानी से पुन: उपयोग करने की अनुमति देता है। मूल रूप से आप अपने मॉडल और अपने नियंत्रकों को प्रोग्राम करते हैं और आप उन्हें वेब ऐप, डेस्क ऐप, सेवा, कहीं भी बिना अधिक प्रयास के अप्रत्यक्ष रूप से उपयोग कर सकते हैं।

Comments

यह केवल UI परत और कार्यात्मक परत को परिभाषित करने से अलग नहीं है। आपने समझा नहीं है कि नियंत्रक बिट क्यों आवश्यक है।

— बिली ओपल

Answer 6

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

Answer 7

मुझे लगता है कि MVC का उपयोग सिद्धांतकारों द्वारा एक चर्चा के लिए किया जाता है जो प्रबंधक हैं। हालाँकि, कहा जा रहा है कि, HTML5 प्रचलित, उत्तरदायी डिजाइन के साथ वेब का वर्तमान पुनरावृत्ति, और डेटाबेस प्रोग्रामिंग की एक पंक्ति बनाने की कोशिश कर रहा है जो वेब पर काम करेगा और iPhone पर MVC के सामान्य विचारों के लिए उधार देता है। वेब फ्रंट-एंड तकनीक शाब्दिक रूप से प्रकाश की गति से चल रही है जो अभी जीक्वेरी के साथ है, सीएसएस नियंत्रण के नए पुनरावृत्तियों, जबकि चीजों का सर्वर पक्ष एक घोंघा की गति से आगे बढ़ रहा है।

आखिरकार, सर्वर पर सब कुछ बस सेवाओं या "एप्लेट्स" होगा जो डेटा को फ्रंट-एंड पर पंप करता है और इस बात पर निर्भर करता है कि आपके पास किस तरह का क्लाइंट है, उस डेटा का उपभोग और अलग तरीके से प्रदर्शित किया जाएगा। उस अर्थ में, MVC समझ में आता है।

इस संबंध में, मेरा मानना ​​है कि वर्तमान वास्तविक दुनिया में, MVVM वास्तव में एक बेहतर "पैटर्न" है या आप इसे कंट्रोलर की तुलना में कॉल करना चाहते हैं क्योंकि एक नियंत्रक को हमेशा दृश्य बदलने के लिए मॉडल पर वापस जाना पड़ता है और यह धीमा है । MVVM पैटर्न में ViewModel दृश्य को तत्काल अपडेट दे सकता है। इसके अलावा MVVM मॉडल रेस्टफुल डिज़ाइन प्रिंसिपल्स IMHO को बढ़ावा देता है।

Comments

क्या यह केवल आपकी राय है, या आप इसे किसी तरह वापस कर सकते हैं?

— कुटकी

(नीचे नहीं किया गया) ठीक है, यह 40+ वर्षों से चल रहा है अगर यह है तो यह एक चर्चा है।

— बिली ओनली

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

से मॉडल देखें नियंत्रक इतिहास :। "MVC 70 में Xerox PARC में आविष्कार किया गया था, जाहिरा तौर पर ट्रिग्वे रीनस्कॉग से मेरा मानना है कि इसकी पहली सार्वजनिक उपस्थिति स्मालटाक -80 में था एक लंबे समय के लिए वहाँ भी स्मालटाक में, लगभग MVC के बारे में कोई सार्वजनिक जानकारी नहीं थी। -80 प्रलेखन। एमवीसी पर प्रकाशित पहला महत्वपूर्ण पेपर "स्मॉलटाक -80 में मॉडल-व्यू-कंट्रोलर यूजर इंटरफेस प्रतिमान का उपयोग करने के लिए एक कुकबुक" था, जो जर्नलऑफऑब्जेक्टऑनवेटप्रोएन्डरमिंग के अगस्त / सितंबर अंक में प्रकाशित हुआ। (Joop)। "

वहाँ KISS की तरह अधिक महत्वपूर्ण कदम उठाए जाने लगे कि अधिक समय के लिए चारों ओर गया है और एक पूरी बहुत कम ध्यान आकर्षित करने की है के बहुत सारे हैं।

— माइकल बार्बर