MVC आर्किटेक्चर - मुझे कितने कंट्रोलर चाहिए?

Question

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

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

सिंगल वेब ऐप के लिए कितने नियंत्रकों की आवश्यकता होती है?

मुझे लगता है कि यह एक उदाहरण के बिना जवाब देना मुश्किल होगा इसलिए मैं एक प्रदान करूंगा:

आवेदन:

1. उपयोगकर्ता लॉग इन करता है।
2. उपयोगकर्ता तीन चीजों में से एक कर सकता है:
   ए) एक फ़ाइल अपलोड करें (मेटा डेटा के साथ एक मोंगोडब डेटाबेस में संग्रहीत)।
   बी) एक फ़ाइल के लिए खोजें।
   c) लॉग आउट करें।

मेरा प्रश्न एक सामान्य है, लेकिन मैंने उदाहरण दिया कि किसी को भी उत्तर देने की कोशिश में मदद करने के लिए।

Comments

एक सच में अच्छी तरह से पूछा सवाल।

— डैनियल हॉलिनरेके

Answer 1

आपके उदाहरण के लिए मैं दो नियंत्रक बनाऊंगा:

• लॉगिन और लॉगआउट के लिए सत्र नियंत्रक (लेआउट की तरह REST के लिए सत्र बनाएं और नष्ट करें)
• फ़ाइलों पर सब कुछ के लिए फ़ाइल नियंत्रक (सूचकांक = खोज और बनाएं = अपलोड करें)

सामान्य तौर पर एक कठोर दृष्टिकोण जहां आप एक संसाधन के रूप में हर चीज के बारे में सोचते हैं जो प्रदर्शित, निर्मित, संपादित और नष्ट हो सकता है, आपको चीजों को संरचना करने का एक अच्छा विचार देता है। जैसा कि आप मेरे उदाहरणों से देख सकते हैं कि मैं REST की हर एक क्रिया के बहुत करीब नहीं हूँ।

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

प्रारंभिक विचार प्राप्त करने के लिए एक बहुत ही मोटा अनुमान आपके डेटाबेस में प्रत्येक तालिका के लिए एक नियंत्रक हो सकता है जिसे उपयोगकर्ता एक्सेस कर सकते हैं। लेकिन यह वास्तव में केवल एक बहुत ही कच्चा माप है।

Comments

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

— जेफ

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

— थोरस्टेन मुलर

Answer 2

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

यदि आपका कंट्रोलर एक या अधिक कोड से ग्रस्त है (विशेषकर लार्ज क्लास या गॉड ऑब्जेक्ट ) तो आपको पता है कि आप शायद उस बिंदु को पार कर रहे हैं जहां सिर्फ एक ही काम करेगा।

Answer 3

यह वास्तव में आपके आवेदन की जरूरतों और व्यापार मॉड्यूल की वास्तुकला पर निर्भर करता है ।

अंगूठे का एक सामान्य नियम , आवश्यक नियंत्रकों की संख्या वेब ऐप में कई मॉड्यूल और उप-मॉड्यूल पर निर्भर करती है।

एक पूरक के रूप में, यह नियंत्रकों को क्षेत्रों में व्यवस्थित करने में सहायक होगा । क्षेत्रों की अवधारणा ASP.NET MVC फ्रेमवर्क में निर्मित है और यह नियंत्रकों के संगठन को सरल करता है जो एक मॉड्यूल की सेवा करते हैं।

संबंधित चर्चाएँ कई हैं:

• MVC आर्किटेक्चर
• ASP.NET MVC नियंत्रक क्रिया डिज़ाइन
• mvc नियंत्रक और निर्देशिका निर्देशिका संगठन देखें
• MVC वर्ग संगठन कई विचारों और नियंत्रकों के लिए कैसा दिखता है?

Comments

महान संदर्भ! मैं उन्हें बाहर की जाँच करने के लिए सुनिश्चित हो जाएगा!

— जेफ

बिलकुल कोई परेशानी नही।

— एल युसुबोव

Answer 4

मुझे इसे करने का एप्पल का तरीका पसंद है।

प्रत्येक दृश्य को केवल एक दृश्य नियंत्रक द्वारा नियंत्रित किया जाता है। ~ IOS के लिए कंट्रोलर प्रोग्रामिंग गाइड देखें

विचार यह है कि आपको आसानी से दृश्य स्वैप करने में सक्षम होना चाहिए। IMO, केवल 1 Controllerप्रति होने Viewसे इसे पूरा करना आसान हो जाता है। लेकिन मुझे यकीन है कि आप कई दृश्यों के साथ एक नियंत्रक हो सकते हैं और फिर भी इसे डिज़ाइन कर सकते हैं ताकि आप प्रोग्राम तर्क को बदलने के बिना दृश्य स्विच कर सकें।

Comments

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

— जेफ

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

— कोरी हिंटन

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

— कोरी हिंटन

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

— ईएल यूसुबोव

@ElYusubov मैं देख सकता हूँ कि यह कहाँ भ्रमित हो सकता है। IOS में प्रत्येक दृश्य में केवल एक दृश्य नियंत्रक होता है और प्रत्येक दृश्य नियंत्रक में केवल 1 सक्रिय दृश्य होता है (और उस दृश्य में उप-दृश्य हो सकते हैं) लेकिन उस दृश्य नियंत्रक में किसी भी दृश्य के संदर्भ भी हो सकते हैं।

— कोरी हिंटन

Answer 5

एक उदाहरण जो मुझे पसंद है वह एक थर्मोस्टैट के बारे में सोच रहा है। एमवीसी पैटर्न को देखने के लिए एक थर्मोस्टैट एक शानदार दृश्य है।

---

एक पुराने, एनालॉग थर्मोस्टेट पर आप इस तरह की चीजें देख सकते हैं:

दृश्य - तापमान रीडर, जो वर्तमान तापमान को प्रदर्शित करता है।

नियंत्रक - डायल, जहां आप तापमान बदलते हैं

मॉडल - इसके अंदर के हिस्से नियंत्रक द्वारा लगाए जाते हैं जो तापमान को बदलते हैं।

---

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

यदि आप MVC आर्किटेक्चर को ठीक से नियोजित करने की बेहतर समझ चाहते हैं, तो GoF से परामर्श करें "डिज़ाइन पैटर्न: पुन: प्रयोज्य के तत्व ... सॉफ़्टवेयर" जो उदाहरण कोड के लिए C ++ और SmallTalk का उपयोग करता है। यह पुस्तक अल्फा और ओमेगा नहीं है, लेकिन यह निश्चित रूप से एक शुरुआत है!

सौभाग्य!

Answer 6

मुझे लगता है कि आपका उदाहरण एक जटिल प्रणाली में विकसित होगा।

आवेदन:

उपयोगकर्ता लॉग इन:

• LoginController

इसकी एकमात्र ज़िम्मेदारी लॉगइन को संभालना, परिणाम के उपयोगकर्ता को फिर से प्रत्यक्ष या अधिसूचित करना है।

एक फाइल अपलोड करें

• UploadController

मैं यहाँ मानता हूँ कि आप किसी भी प्रकार की फ़ाइल अपलोड करना चाहते हैं। यदि बाद की तारीख में आप MP3 और PDF अपलोड करने का निर्णय लेते हैं, तो मेरे पास आधार UploadController, MP3UploadController और PDFUploadController होगा।

एक फ़ाइल के लिए खोजें।

• SearchFileController

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

लॉग आउट।

- LogoutController।

कोई इसे ओवरकिल मान सकता है, लेकिन मुझे नहीं लगता कि यह है। मुझे लगता है कि यह साफ है और अच्छी तरह से अलग है।

अगर मुझे इस परियोजना के ढांचे को देखना है, तो मुझे तुरंत पता चल जाएगा कि यह क्या करता है और यह कैसे संरचित है। यह एक कदम आगे ले करने के लिए, मैं रखा LoginControllerऔर LogoutControllerअलग क्षेत्र में।

मैंने पहले भी ऐसा कुछ विकसित किया है और यह वास्तव में अच्छी तरह से काम करता है।

Comments

इनपुट के लिए धन्यवाद! कोई काम कोड मिला? कुछ चीजों पर अटक जाना।

— जेफ

आप किन समस्याओं का सामना कर रहे हैं?

— कोडर

मैं एक विषय और एक तारीख (स्ट्रिंग प्रारूप में) अपलोड करने में सक्षम हूं, लेकिन फ़ाइल को स्वयं अपलोड नहीं कर सकता (देखें stackoverflow.com/questions/18344614/… )।

— जेफ

मैं एक .NET डेवलपर हूं। क्षमा करें, मैं आपकी मदद नहीं कर सकता।

— कोडार्ट

Answer 7

आपका अधिकांश कोड व्यवसाय परत में सही होगा? यदि ऐसा है तो आप वास्तव में अपने कंट्रोलर में जो कर रहे हैं वह डेटा को व्यू में लौटा रहा है।

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

लॉजिक यूनिट प्रति नियंत्रक के लिए बेहतर है, उदाहरण के लिए अकाउंटकंट्रोलर (लॉगिन, पंजीकरण, लॉगआउट), फाइलकंट्रोलर (खोज, अपलोड) और इसी तरह।

Answer 8

सामान्य तौर पर आप कह सकते हैं कि प्रत्येक मॉडल का अपना नियंत्रण और समर्पित दृश्य हैं। सामान्य कहने से मेरा मतलब है कि यह सबसे अच्छा अभ्यास है।

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

याद रखें कि सभी नियंत्रकों को मूल रूप से मॉडल पर CRUD संचालन को संभालना चाहिए और विभिन्न फ़िल्टर के लिए विभिन्न विचारों का उपयोग करना चाहिए।

मेरी राय में पैटर्न के रूप में एमवीसी के प्रमुख लाभों में से एक यह है कि यह मॉडल और विचारों को टाई करने का सबसे अच्छा तरीका है।

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

Comments

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

— gnat

@gnat मैं आपकी टिप्पणी को स्वीकार करता हूं, संपादित उत्तर देखें

— शनि टेक्नोलॉजीज