एमवीसी में आप अपने नियंत्रक को क्या नाम देना चाहिए? आपको एक नया कब बनाना चाहिए?

Question

मेरे पास एक प्रश्न है जो वास्तव में किसी भी एमवीसी ढांचे पर लागू होता है, मैं ज़ेंड फ्रेमवर्क एमवीसी का उपयोग कर रहा हूं।

जब आपको बिल्कुल नया नियंत्रक बनाना चाहिए? कंट्रोलर परत को वास्तव में क्या परिभाषित करना चाहिए?

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

क्या किसी के पास कुछ ह्यूरिस्टिक्स/दिशानिर्देशों का पालन करने के लिए है? एमवीसी के बारे में सभी प्रचारों की तरह लगता है, खासकर PHP के साथ, वास्तविक सम्मेलनों और हेरिस्टिक्स पर बहुत कम डेटा है। चूंकि एक असंगठित एमवीसी अनुप्रयोग बनाना बहुत आसान है ...

Answer 1

मेरे पास आमतौर पर कार्यों के प्रत्येक तार्किक समूह के लिए एक नियंत्रक होता है। अक्सर यह प्रति मॉडल एक नियंत्रक के साथ मेल खाता है, कभी-कभी नहीं।

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

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

दृश्यों में आपकी प्रस्तुति की संपूर्णता शामिल है। नियंत्रक/मॉडल HTML उत्पन्न या संभाल नहीं करना चाहिए। 2 कॉलम या 3 जैसे निर्णय विचारों में हैं। दृश्यों में तर्क उस दृश्य तक सीमित होना चाहिए जो दृश्यमान आउटपुट उत्पन्न करने के लिए आवश्यक है। यदि आप स्वयं को डेटाबेस से क्वेरी से पूछना चाहते हैं, तो आप शायद दृश्य में बहुत अधिक तर्क डाल रहे हैं।

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

Answer 2

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