MVC के पतन क्या हैं? [बन्द है]

Question

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

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

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

Comments

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

— gnat

मुझे आपके प्रश्न का उत्तर देने से पहले MVC की क्या परिभाषा है, इस बारे में मुझे एक उत्तर की आवश्यकता होगी क्योंकि MVC वास्तुकला केवल समस्याओं के एक सेट पर लागू होती है। इसलिए यदि आप इसे गलत जगह पर उपयोग करते हैं तो आपके पास गिरावट है।

— बेन मैकडॉगल

आपकी विभिन्न नौकरियों में कितनी विविधता है?

— जेएफओ

'एमवीसी ऑब्जेक्ट ओरिएंटेड नहीं है' का एक पाठ पढ़ें ।

— mcintyre321

@ जेफ़ो PHP ऐप (बैकएंड, नॉन-जेएस हैवी साइट्स), फ्रंट-एंड ऐप्स। तो, सभी वेब, लेकिन फ्रंट-एंड और बैकएंड।

— ऑस्कर गोडसन

Answer 1

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

यह मेरी सबसे बड़ी गलती थी। मैंने उस सरल नियम को समझने में एक लंबा समय बिताया:

• पूरे आवेदन के बीच एक एमवीसी पैटर्न न फैलाएं,
• इसे केवल UI से संबंधित सामग्री तक सीमित रखें।

हमेशा जांचें कि क्या आप जो कोड लिखते हैं वह तार्किक रूप से सही जगह पर है, इसका अर्थ है कि यह तार्किक रूप से उस वर्ग की जिम्मेदारी के क्षेत्र में फिट बैठता है जो इसे जगह देता है। यदि नहीं - तो जैसे ही आप इसे समझते हैं कोड को हटा दें।

सभी पैटर्न जिन्हें आप एमवीसी-विकल्प कहते हैं (यानी मॉडल-व्यू-प्रस्तोता, मॉडल-व्यू-व्यूमॉडल) सामान्य एमवीसी अवधारणा को लागू करने का एक तरीका है।

Comments

वास्तव में आप एमवीसी को कभी भी लागू कर सकते हैं आपके पास एक अमूर्त परत है; एपीआई दृश्य / नियंत्रक है और अंतर्निहित तर्क मॉडल है

— शाफ़्ट सनकी

@ratchetfreak, तकनीकी रूप से एक API बोलना UI का एक रूप है, जहाँ उपयोगकर्ता API का उपयोग करने वाला प्रोग्रामर है।

— zzzzBov

@ratchetfreak: क्या इसे फ़ेकड पैटर्न के रूप में वर्गीकृत नहीं किया जाएगा?

— Jeroen Vannevel

MVC UI में सबसे अधिक उपयोगी हो सकता है, लेकिन यह चिंताओं को अलग करना शायद ही केवल वहां उपयोगी है।

— डग्म

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

— जेवियर

Answer 2

मेरी राय में दो प्रकार के MVC हैं - शुद्ध और अशुद्ध (एक बेहतर शब्द की कमी के लिए :)

शुद्ध MVC छोटी बात में पेश किया गया था:

यह व्यक्तिगत कंप्यूटिंग / डेस्कटॉप अनुप्रयोगों के लिए अभिप्रेत था। जैसा कि आप देख सकते हैं, मॉडल किसी भी अपडेट / उसमें किए गए परिवर्तनों के विचारों को सूचित करता है। ऐसा नहीं है (अशुद्ध) MVC के साथ।

अन्य (अशुद्ध) एमवीसी जो वेब अनुप्रयोगों के लिए टाल दिया गया है, ऊपर के क्लासिक एमवीसी के बजाय पीएसी ( प्रस्तुति-गर्भपात-नियंत्रण ) पैटर्न का अधिक है। यह कोड संगठन और चिंताओं को अलग करने का अधिक है:

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

अब, यहां बताया गया है कि आमतौर पर एक वेब एप्लिकेशन कैसे संरचित होता है:

1. फ्रंट-एंड : बैकऑन.जेएस आदि के रूप में फ्रेमवर्क का उपयोग करते हुए क्लाइंट पर एमवीसी, यह सार में 'सही' एमवीसी फॉर्म है।
2. बैक-एंड : फिर से, आपके पास (अशुद्ध) कोड संगठन और चिंताओं को अलग करने के लिए MVC / PAC है
3. ग्लोबल वेब ऐप (संपूर्ण रूप में वेब एप्लिकेशन के लिए): यदि आपके पास RESTful बैकएंड है जो केवल JSON डेटा लौटाता है, तो आपके पूरे बैकएंड को फ्रंट-एंड क्लाइंट एप्लिकेशन के लिए एक मॉडल के रूप में माना जा सकता है जहां व्यू और कंट्रोलर सार में रहते हैं।

तो एमवीसी के कुछ नुकसान क्या हैं ? ठीक है, पैटर्न समय की कसौटी पर खरा उतरा है, इसलिए इसमें बहुत से ऐसे मामले नहीं हैं, जो इसके अलावा कुछ 'जटिल' हो। आप देखते हैं, एमवीसी एक मिश्रित पैटर्न है - रणनीति / पर्यवेक्षक पैटर्न को लागू करता है और सभी उच्च स्तरीय पैटर्न बनाने के लिए अच्छी तरह से व्यवस्थित होते हैं।

क्या आपको हर जगह इसका इस्तेमाल करना चाहिए? शायद नहीं। बहुत जटिल वेब अनुप्रयोग शायद कई परतों में विभाजित हो जाते हैं! आप केवल व्यू / बिजनेस लॉजिक / डेटा लेयर्स के साथ नहीं निकल सकते। ओवररचिंग फ्रेमवर्क / संगठन अभी भी एमवीसी-ईश हो सकता है, लेकिन केवल एक मैक्रोस्कोपिक स्तर पर।

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

Comments

"शुद्ध बनाम अशुद्ध" के लिए +1। हालाँकि मैं "GUI बनाम वेब MVC" का उपयोग करना पसंद करता हूं, और इंगित करता है कि GUI MVC मॉड्यूलर है जबकि वेब MVC स्तरित है । मैं वास्तव में चाहता हूं कि वेब एमवीसी को कुछ और कहा जाता था, क्योंकि यह "शुद्ध एमवीसी" से बहुत अलग है, लेकिन ऐसा लगता है कि इसके लिए बहुत देर हो चुकी है।

— जेवियर

मुझे डायग्राम पसंद है। पुन। शब्दांकन, शायद "पारंपरिक एमवीसी बनाम व्युत्पन्न एमवीसी" :)

— एडविन यिप

Answer 3

बहुत सारे लोग डिजाइन पैटर्न के साथ गलती करते हैं यह देख रहा है कि यह एक जगह पर खूबसूरती से काम करता है और फिर इसे हर जगह लागू करने की कोशिश कर रहा है।

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

जहां तक ​​इसका उपयोग नहीं करना है। खैर, जहां भी MVC ट्रिपलेट का एक तत्व लागू नहीं होता है। कंसोल एप्लिकेशन किसी इंटरफ़ेस को लागू नहीं कर सकते हैं। उपयोगिता कार्यक्रमों में एक मॉडल नहीं हो सकता है। और यकीनन, यदि आपके पास न तो कोई मॉडल है और न ही कोई दृश्य है, तो आपको नियंत्रक की आवश्यकता नहीं है।

समस्या शायद ही अवधारणा के साथ है - कार्यान्वयन के साथ और अधिक। कोई भी बात नहीं है कि प्रतिमान कितना अच्छा है, यह देखने के लिए समय निकालें कि क्या यह हाथ में समस्या के लिए एक अच्छा फिट है।

Comments

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

— डग एमजी

कंसोल एक यूआई है। बस पाठ आधारित है, इसलिए आपकी धारणा गलत है।

— गार्जियनएक्स

@GuardianX मैं वास्तव में उस शब्द को बहुत अच्छी तरह से नहीं जानता था। मैंने अपना उत्तर स्पष्ट करने के लिए संपादित किया है।

— रॉबी डी

Answer 4

MVC, जैसे किसी भी प्रतिमान आपके विकास मंच का अभिन्न अंग नहीं है, जटिलता बढ़ जाती है। यह दोष यह है कि आप अलग-अलग वर्गों को अलग कर सकते हैं जो अलग-अलग नहीं होने चाहिए, और यह स्पष्ट रूप से कम हो जाएगा कि वे कितने कसकर बंधे हुए हैं। (या, तुच्छ परियोजनाओं के लिए, यहां तक ​​कि आपके कोड को भी बाधित करना।)

पहली समस्या का विकल्प ऐसे कोड को स्वतंत्र उप-परियोजनाओं में अलग करना है; दूसरे के लिए विकल्प अन-सेप्रेटेड कोड है, या तो क्लास या फाइल मॉडल पर।

Comments

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

— रोबी डी

@ रोबी: आह !! अनवरत वृद्धि # अनियंत्रित विस्तार!

— डौगएम

Answer 5

एमवीसी / एमवी * लगाने की मेरी समझ सेपरेशन ऑफ सेपरर्न्स (SoC) के सिद्धांत का पालन कर रही है - प्रोग्राम / कोड्स को अलग-अलग वर्गों / टुकड़ों में अलग करना ताकि प्रत्येक अनुभाग एक अलग चिंता को संबोधित कर सके (Ref: http://en.wikipedia.org / विकी / सेपरेशन_ऑफ_केंसर )

चिंताओं को अलग करते समय बहुत सारे लाभ हैं: एक और को प्रभावित नहीं करेगा और डेवलपर्स बाकी को प्रभावित किए बिना एक इकाई पर काम कर सकते हैं, आदि और आदि ... MVC एकमात्र पैटर्न नहीं है जो SoC का अनुसरण करता है, मूल रूप से, OOP ही है इकाइयों में चीजों को तोड़ने के लिए एक महान अवधारणा।

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

इस प्रकार, एमवीसी की कमियों के बारे में बात करते समय, यह वास्तव में उन परियोजनाओं पर निर्भर करता है जो आप कर रहे हैं - क्या इसमें यूआई है? क्या इसके लिए महान मापनीयता / व्यापकता की आवश्यकता है? क्या UI और बैक-सिस्टम के बीच कई इंटरैक्शन हैं? उदाहरण के लिए, एक साधारण सूचना वेब पेज को MVC की बिल्कुल भी आवश्यकता नहीं है, जब तक कि आप इसे भविष्य में एक महान इंटरैक्टिव पेज तक विस्तारित करने की योजना नहीं बनाते हैं।

इसलिए MVC (या अधिक सामान्य - एक डिज़ाइन पैटर्न) का मूल्यांकन करने के लिए, इसे एक संदर्भ दें और जटिलता, मापनीयता, परीक्षण, रखरखाव, समय की कमी, और आदि के बारे में सोचें।