MVC आर्किटेक्चर में, कंट्रोलर को मॉडल और व्यू कितनी बारीकी से मिलते हैं?

Question

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

बस एक संपादन के रूप में; यह एक कस्टम ऐप है जिसे किसी भी वेब फ्रेमवर्क में नहीं लिखा गया है, इसलिए मैं यहां फ्रेमवर्क-विशिष्ट विवरणों की तलाश नहीं कर रहा हूं और मुझे अपनी पसंद बनाने की स्वतंत्रता है।

Comments

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

— स्टीवन एवर्स

@SnOrfus: यह मेरे विचार से बिलकुल विपरीत है- M & V, C से युग्मित हैं लेकिन एक दूसरे से नहीं।

— डेडएमजी

इतने सारे उत्तर इतने गलत कैसे हो सकते हैं। यहाँ MS के संस्करण को पढ़ें msdn.microsoft.com/en-us/library/ff649643.aspx

— Reactgular

इस लेख को पढ़ें: objectmentor.com/resources/articles/taskmast.pdf

— एडवर्ड स्ट्रेंज

Answer 1

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

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

यह दृश्य डेटा के लिए भी युग्मित है, लेकिन दृश्य स्वयं नहीं। अर्थात। यह बस कहता है "इस ग्राहक विवरण का उपयोग करके ग्राहक का दृश्य दिखाएं।" फ्रेमवर्क यह तय करता है कि उसे वह दृश्य कहां मिलना चाहिए।

अब यह आपको उसी डेटा के व्यू मॉडल का उपयोग करके, डोमेन मॉडल को देखने से हटाने की अनुमति दे सकता है। कुछ डेवलपर्स ऐसा करते हैं, कुछ नहीं करते हैं, और मुझे लगता है कि यह काफी हद तक व्यक्तिगत प्राथमिकता का मामला है।

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

.NET की दुनिया में, हम उन चीजों को अनुमति न देकर जोखिम को कम करते हैं जो कि नहीं होनी चाहिए और संभवत: इस कारण से, यह मुझे लगता है कि अलग किया गया मॉडल अधिक लोकप्रिय है।

Comments

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

— कोडर्ट

Answer 2

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

tl; dr: MVC के संदर्भ में अपने ऐप के बारे में न सोचें और योजना बनाएं। MVC फ्रेमवर्क केवल एक कार्यान्वयन विवरण है।

MVC के बारे में सबसे भ्रामक बात यह है कि, डेवलपर्स एक साथ चिपके सभी घटकों का उपयोग करने की कोशिश करते हैं।

किसी कार्यक्रम के संदर्भ में सोचने की कोशिश करें, न कि रूपरेखा के संदर्भ में।

आपके कार्यक्रम का एक उद्देश्य है। यह कुछ डेटा लेता है, डेटा के साथ काम करता है, और कुछ डेटा लौटाता है।

इस तरह, controllerआपके कार्यक्रम का वितरण तंत्र है।

1. एक उपयोगकर्ता आपके कार्यक्रम के लिए एक अनुरोध भेजता है (मान लें कि, शॉपिंग कार्ट में एक उत्पाद जोड़ें)।
2. नियंत्रक उस अनुरोध (उत्पाद जानकारी और उपयोगकर्ता जानकारी) को लेता है, यह आपके कार्यक्रम के आवश्यक हिस्से को कॉल करता है जो इस अनुरोध को संभाल लेंगे $user->addToCart($product)
3. आपका कार्यक्रम ( इस मामले में वस्तु addToCartका कार्य user) वह काम करता है जो वह करने का इरादा रखता है और एक प्रतिक्रिया देता है (चलो कहते हैं success)
4. नियंत्रक संबंधित का उपयोग करके प्रतिक्रिया तैयार करता है view: जैसे। नियंत्रक वस्तु में$this->render($cartView('success')

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

यदि आप किसी अन्य ढांचे का उपयोग करना चाहते हैं, तो आपके ऐप को बदलाव की आवश्यकता नहीं होगी, आपको अनुरोधों के लिए अपने प्रोग्राम को कॉल करने के लिए प्रासंगिक नियंत्रकों को लिखना होगा।

या यदि आप एक डेस्कटॉप संस्करण बनाना चाहते हैं, तो आपका ऐप वही रहेगा, आपको बस एक डिलीवरी तंत्र तैयार करना होगा।

और द Model। इसे एक दृढ़ता तंत्र के रूप में सोचें।

OO तरीके से, आपके प्रोग्राम में ऑब्जेक्ट हैं जो डेटा को धारण करते हैं।

class User {
    //...
    private $id;
    private $shoppingCart;
    //...
}

class Product {
    //...
    private $id;
    //...
}

आप खरीदारी की टोकरी में कोई उत्पाद जोड़ते हैं, तो आप जोड़ सकते हैं product::idकरने के लिए user::shoppingCart।

और जब आप डेटा को जारी रखना चाहते हैं, तो आप modelफ्रेमवर्क के उस भाग का उपयोग कर सकते हैं , जिसमें आम तौर पर एक ORM का उपयोग होता है, जो कक्षाओं को डेटाबेस टेबल पर मैप करता है।

यदि आप अपने द्वारा उपयोग किए जाने वाले ORM को बदलना चाहते हैं, तो आपका प्रोग्राम वही रहेगा, केवल मैपिंग की जानकारी बदल जाएगी। या यदि आप सभी एक साथ डेटाबेस से बचना चाहते हैं, तो आप डेटा को सादे पाठ फ़ाइलों में लिख सकते हैं, और आपका ऐप समान रहेगा।

---

इसलिए, पहले अपना प्रोग्राम लिखें। यदि आप 'OO' तरीके से प्रोग्रामिंग करते हैं, तो भाषा की पुरानी पुरानी वस्तुओं का उपयोग करें। पहले MVC के संदर्भ में मत सोचो।

Comments

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

— एडवर्ड स्ट्रेंज

हाँ, मैंने लिखा है कि जिस तरह से लोग सोचते हैं कि क्या MVCहै। इसलिए मैंने लिखा है MVC Framework।

— हकन डेरिल

Answer 3

मार्टिन फाउलर एमवीसी प्रतिमान का वर्णन करने का एक अच्छा काम करता है। यहाँ पर उनके लेख का लिंक है http://martinfowler.com/eaaDev/uiArchs.html

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

Answer 4

यहाँ एक सामान्य उदाहरण है कि MVC का उपयोग एक सामान्य जावा स्विंग एप्लीकेशन में कैसे किया जा सकता है ...

मान लीजिए कि आपके पास एक पैनल है जिसमें एक बटन और एक टेक्स्टफिल्ड है। जब बटन दबाया जाता है, तो एक घटना को निकाल दिया जाता है, जिससे एप्लिकेशन में कुछ स्थिति बदल जाती है। एक बार जब राज्य परिवर्तन पंजीकृत हो जाता है, तो TextField अक्षम हो जाता है।

यह, तब, एक साधारण MVC एप्लिकेशन द्वारा लिया गया विशिष्ट दृष्टिकोण होगा ...

नियंत्रक स्वयं को व्यू के ईवेंट के श्रोता के रूप में पंजीकृत करता है। जब बटन पर क्लिक किया जाता है, तो दृश्य स्वयं घटना को नहीं संभालता है; नियंत्रक करता है। नियंत्रक स्विंग विशिष्ट है क्योंकि यह स्विंग संबंधित घटनाओं से निपटना चाहिए।

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

संदेश उचित संदर्भ में मॉडल द्वारा प्राप्त किया जाता है। यही है, यह स्विंग या किसी अन्य जीयूआई विशिष्ट संदर्भों के किसी भी संदर्भ से पूरी तरह से शून्य है। यह संदेश मॉडल और केवल मॉडल के लिए बोलता है। यदि आप स्वयं को मॉडल में javax.swing स्टेटमेंट आयात करते हुए पाते हैं, तो आप मॉडल को सही ढंग से कोड नहीं कर रहे हैं।

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

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

Answer 5

युग्मन (जिस तरह से आप बचना चाहते हैं) में दो वर्गों के बीच पारस्परिक निर्भरता शामिल है । यही है, एक फू एक बार पर निर्भर करता है और एक बार एक फू पर निर्भर करता है ताकि आप वास्तव में एक को दूसरे को संशोधित किए बिना संशोधित न कर सकें। यह एक बुरी बात है।

आप वास्तव में कुछ निर्भरता होने से बच सकते हैं, हालांकि। कक्षाओं को एक दूसरे के बारे में थोड़ा जानना होगा, अन्यथा वे कभी संवाद नहीं करेंगे।

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

अनिवार्य रूप से, नियंत्रक अप्रत्यक्ष स्तर है जो मॉडल से व्यू को डिकूप करता है, ताकि उन्हें एक-दूसरे के बारे में जानना न पड़े।

Comments

आह - यही कारण है कि नीचे - मैं गलत व्याख्या करता हूं। मेरा मतलब था कि नियंत्रक की दोनों पर निर्भरताएं हैं। डी 'ओह!

— मैथ्यू फ्लिन

Answer 6

मेरे अनुभव में, आमतौर पर मॉडल केवल एक दृश्य पर निर्भर करता है , न कि एक विशिष्ट पर, अक्सर एक पर्यवेक्षक के रूप में ... अगर ऐसा कोई युग्मन है।

आम तौर पर जो कुछ भी दिख रहा है, उसे देखने के लिए, जो समझ में आता है। एक दृश्य के साथ आने के लिए मुश्किल है जो इसे देख रहा है से डिकॉउन्ड किया जा सकता है ... लेकिन कभी-कभी आपके पास आंशिक युग्मन या कुछ और हो सकता है।

नियंत्रक अक्सर दोनों को जोड़े जाता है। यह भी कुछ समझ में आता है क्योंकि यह काम है घटनाओं को मॉडल परिवर्तनों में बदलना।

बेशक, यह केवल एक प्रवृत्ति है जिसे मैंने देखा है और वास्तव में किसी भी विशिष्ट उदाहरण के बारे में कुछ नहीं कहता है।

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

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

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

---

उन लोगों के लिए जो सोचते हैं कि वे बेहतर जानते हैं:

http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod

http://msdn.microsoft.com/en-us/library/ff649643.aspx

मुझे यकीन है कि और भी हैं, लेकिन वे Google में सूची में सबसे ऊपर हैं। जैसा कि आप देख सकते हैं, मॉडल बहुत MANY कार्यान्वयन में एक दृश्य इंटरफ़ेस पर निर्भर करता है। आमतौर पर एक मॉडल अवलोकनीय है और दृश्य एक पर्यवेक्षक है।

लेकिन तथ्यों को रास्ते में आने दें ...

पहले से ही दूसरे उत्तर में पोस्ट किया गया एक लेख भी मेरे बयानों का समर्थन करता है:

http://martinfowler.com/eaaDev/uiArchs.html

अगर लोग यह कहना जारी रखना चाहते हैं कि डिजाइन उद्योग में हर कोई गलत है तो यह ठीक है।

Comments

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

— फाल्कन

उत्तर गलत है। मॉडल एक दृश्य या नियंत्रक पर निर्भर नहीं करता है।

— कोडर्ट

@Crazy एडी आपने कहा: "मेरे अनुभव में, आमतौर पर मॉडल केवल एक दृश्य पर निर्भर करता है, न कि एक विशिष्ट पर, अक्सर एक पर्यवेक्षक के रूप में" आपका उद्धृत संदर्भ कहता है: "हालांकि, मॉडल न तो दृश्य और न ही नियंत्रक पर निर्भर करता है।" क्या आपने उद्धृत लेख भी पढ़ा है? ऐसा नहीं लगता है।

— कोडार्ट

@ क्रेजी एडी: मुझे परवाह नहीं है कि भद्दा कोडप्रोजेक्ट पर कोई क्या लिखता है। यह एक भयानक डिजाइन है। परिवर्तनों को सुनने के लिए एक पर्यवेक्षक का उपयोग करना ठीक है, लेकिन एक डोमेन मॉडल में एक प्रस्तुति इंटरफ़ेस डालना ओह इतना गलत है। लेख से उद्धृत कोड MVC के संबंध में कुछ मौलिक तरीकों से त्रुटिपूर्ण है। यह भी मॉडल को नियंत्रक पर निर्भर करता है। क्या बकवास है।

— फाल्कन

@ क्रेजी एडी: lol @ downvote हिसात्मक आचरण। क्या मैंने तुमसे दुश्मनी की?

— फाल्कन

Answer 7

• नियंत्रक एक दृश्य के लिए मॉडल भेजता है और यह विचारों से मॉडल प्रस्तुत करता है, हालांकि इसे कसकर किसी दृश्य या मॉडल से जोड़ा नहीं जाता है।

यदि नियंत्रक को किसी दृश्य के साथ युग्मित किया गया था, तो हम वेब रूपों की दुनिया में होंगे। आपके पास एक कोड होगा जिसे एक टेम्पलेट फ़ाइल से जोड़ा जाएगा (ASP.NET वेब प्रपत्रों पर लागू)

इस वजह से, नियंत्रक एक मॉडल या एक दृश्य के लिए युग्मित नहीं है। यह केवल अनुरोधों को संसाधित करने और प्रतिक्रियाएं भेजने के लिए एक तंत्र है।

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

• मॉडल को कसकर एक दृश्य में युग्मित नहीं किया जाता है। किसी दृश्य में परिवर्तन करें, और इसका किसी मॉडल पर कोई प्रभाव नहीं पड़ेगा।

• मॉडल नियंत्रक या विचारों के बारे में कुछ भी नहीं जानता है जहां इसका उपयोग किया जा सकता है। इसलिए मॉडल को कसकर किसी दृश्य या नियंत्रक से जोड़ा नहीं जाता है।

इस बारे में सोचने का दूसरा तरीका:

• एक नियंत्रक में परिवर्तन करें - दृश्य और मॉडल अप्रभावित रहेंगे

• एक मॉडल में परिवर्तन करें - दृश्य टूट जाएगा क्योंकि यह एक मॉडल पर निर्भर करता है

• एक दृश्य में परिवर्तन करें - मॉडल और नियंत्रक अप्रभावित रहेंगे

MVC परियोजनाओं में यह ढीली युग्मन इकाई परीक्षण के लिए आसान बनाता है।

Comments

यह बहुत गलत है यह मज़ेदार नहीं है। समझाने लायक भी नहीं। बस इस जवाब को पूरी तरह से नजरअंदाज करें।

— रिएक्टगुलर

@ मैथ्यू फोसकारिनी रोना बंद करो और एक "सही उत्तर" छोड़ दो

— कोडर्ट

योग्य, MVC के पीछे का पूरा डिजाइन सिद्धांत यह है कि वे एक दूसरे पर निर्भर नहीं हैं।

— रिएक्टगुलर

मैंने आपके लिए और जानकारी छोड़ दी है, उम्मीद है कि यह समझ में

— आएगा