एमवीसी: मॉडल, दृश्य और नियंत्रक को अलग क्यों करें?

Question

इसके "दार्शनिक" पहलुओं के अलावा, क्या मेरा नियंत्रक मेरा मॉडल भी होना एक बुरा विचार है?

ऐसा लगता है कि कुछ प्रोग्रामिंग समय बचा है। मुझे नियंत्रक और मॉडल के बीच तर्क बनाने की ज़रूरत नहीं है, क्योंकि यह वही बात है। और मैं सीधे दृश्य के साथ बातचीत कर सकता हूं।

एम और सी को अलग करने का क्या मतलब है? मॉड्यूलरिटी है - यानी, एक मॉडल और नियंत्रक को दूसरे के लिए सेट करने की क्षमता - उन्हें अलग करने का एकमात्र कारण है? ऐसा लगता है कि "स्वैपिंग" मॉड्यूल आउट मॉडल और नियंत्रक दोनों को अपडेट करने के लिए बहुत कम होता है (उदाहरण के लिए) मॉडल में कुछ बदल रहा है।

---

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

Answer 1

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

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

चीजों को विभाजित करने के अन्य तरीके हैं। कुछ भाषाओं को प्रतिनिधिमंडल के बजाय भारी मात्रा में उपclass। लेकिन कोको में, कार्यक्रमों को विभाजित करने का प्राथमिक माध्यम एमवीसी है, और यह बहुत अच्छी तरह से काम करता है।

संपादित करें: वाणिज्यिक ऐप्स विकसित करने की दुनिया से कुछ और कारण हैं।

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

• मॉडल ऑब्जेक्ट्स को क्रमबद्ध करना आसान है जो नियंत्रकों और विचारों के साथ लिपटे नहीं हैं, और एक ही डेटा को कई तरीकों से प्रदर्शित करना बहुत आसान है। यहां तक ​​कि एक "सरल" टेक्स्ट एडिटर में, आप स्प्लिट-स्क्रीन करने में सक्षम होना चाहते हैं, या एक ही दस्तावेज़ को दिखाने वाली कई खिड़कियां हैं। एमवीसी में यह बहुत आसान है।

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

---

संपादित करें 2: मैं अपने पहले संपादित देख रहा था: "यह अजीब लगता है कि एक सरल कैलकुलेटर, MVC अवधारणा के अनुसार, दोनों एक नियंत्रक और (डिफ़ॉल्ट सेटिंग की तरह अपनी सेटिंग्स के लिए एक दृश्य होना चाहिए , या कुछ)। "

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

Answer 2

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

कल्पना करें कि 10 डेवलपर आपके नियंत्रक पर काम करने की कोशिश कर रहे हैं। लेकिन वे जो करना चाहते हैं वह मॉडल में कुछ जोड़ना है। अब आपका नियंत्रक तोड़ दिया? उन्होंने क्या किया?

Answer 3

मॉडल आमतौर पर अलग-अलग घटक होते हैं जिन्हें नियंत्रकों के बीच फिर से उपयोग किया जा सकता है। यदि आप बिल्कुल निश्चित हैं कि आप एकाधिक नियंत्रक में मॉडल का पुन: उपयोग नहीं करेंगे, तो मुझे इन चिंताओं को मिश्रित करने में कोई समस्या नहीं दिखाई दे रही है।

मुझे लगता है कि कोई तर्क दे सकता है कि यदि आप विचलन करने की योजना बना रहे हैं तो एमवीसी डिज़ाइन का उपयोग क्यों करें। हो सकता है कि आपकी स्थिति के लिए पालन करने के लिए एक और उपयुक्त पैटर्न हो। क्या आप हमें कुछ ऐसा करने का उदाहरण दे सकते हैं जहां नियंत्रक मॉडल है? यह हमें समझने में मदद करेगा कि आप बेहतर करने की कोशिश कर रहे हैं।

Answer 4

एमवीसी एक मानक पैटर्न है जो विकास समुदाय में अच्छी तरह से समझा जाता है, और अच्छे कारणों से। अलगाव वास्तव में चीजों को पढ़ने में आसान बनाता है, समस्या निवारण में आसान है, खोजने में आसान है, और परीक्षण करने में आसान है, व्यक्तिगत घटकों के रूप में, प्रत्येक जिम्मेदारी के अपने क्षेत्र के साथ।

क्या आपको इसका उपयोग करना है? बिलकूल नही। लेकिन भागों को अलग रखने के लिए आम तौर पर एक अच्छा विचार माना जाता है।

Answer 5

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

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

संयोजन मॉडल और नियंत्रक मेरी राय में एक क्लासिक झूठी अर्थव्यवस्था है। ऐसा लगता है कि यह कुछ मिनट बचाता है, लेकिन यह एप्लिकेशन महत्वपूर्ण रूप से बढ़ता है और बढ़ता है।

Answer 6

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

ईमानदारी से, मेरे अधिकांश कॉलेज प्रोगोगिंग असाइनमेंट में, मैंने मॉडल और नियंत्रकों को संयुक्त किया, क्योंकि मुझे अलगाव की आवश्यकता नहीं दिखाई दे रही थी। लेकिन बड़ी परियोजनाओं पर काम करना? यदि आप अलग नहीं होने की कोशिश करते हैं तो कमी बहुत स्पष्ट होगी। बस वही करें जो आपको सही लगता है।

Answer 7

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