एमवीसी में, नियंत्रक वर्ग में निजी, गैर-कार्रवाई, कार्यों के लिए अच्छा अभ्यास माना जाता है?


10

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

क्या नियंत्रक वर्ग में इन विशाल कार्य कार्यों को छोटे निजी कार्यों में तोड़ने के लिए अच्छा व्यवहार माना जाएगा या इस तरह के अनुकूलन की आवश्यकता का मतलब है कि हमें उन्हें मॉडल में जोड़ना चाहिए?

मैं नियंत्रक में निजी के रूप में छोटे कार्यों को करने के लिए मतदान करूंगा ताकि वे कार्रवाई के सापेक्ष हों, लेकिन मैंने तर्क दिए हैं कि नियंत्रक अधिमानतः सरल होना चाहिए जबकि मॉडल विशाल और स्पष्ट हो सकता है; और बस सोच रहा था कि कौन सा सबसे पसंदीदा तरीका होगा।

जवाबों:


16

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

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

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


रचनात्मक सादृश्य के लिए +1। :) आप एक दिलचस्प बिंदु बनाते हैं। ख़ासकर बुरी आदत के बनने पर। धन्यवाद।
डेविड 'गंजा अदरक'

8

सबसे अच्छा जवाब जो मैं दे सकता हूं, वह रॉबर्ट मार्टिन की किताब "क्लीन कोड" से उद्धृत करना है कि मैं इस विषय में रुचि रखने वाले किसी व्यक्ति को अत्यधिक सलाह देता हूं:

कार्यों का पहला नियम यह है कि वे छोटे होने चाहिए। दूसरा नियम यह है कि उन्हें इससे छोटा होना चाहिए।

इसे बेहतर नहीं कह सकते। एक ही किताब से एक और महान उद्धरण लागू होता है:

कार्यों को एक काम करना चाहिए। उन्हें इसे अच्छी तरह से करना चाहिए। उन्हें ही करना चाहिए।

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

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


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

1
@Aaronaught I को "कुछ तर्क" के साथ अस्पष्ट किया गया था, जो मेरे मन में था वह है उदाहरण के लिए Backbone.js पुस्तकालय, जहाँ आप उपयोगकर्ता घटनाओं और कार्यों को अपने विचार में उन्हें संभालने के लिए रखते हैं। शास्त्रीय MVC में यह नियंत्रक का काम है। हालाँकि यह अव्यावहारिक हो सकता है क्योंकि आपको अपने UI में परिवर्तन होने पर हर बार व्यू और कंट्रोलर दोनों को समायोजित करने की आवश्यकता होगी। अपने UI हैंडलर फ़ंक्शन को व्यू में डालकर, आपको केवल व्यू को समायोजित करने की आवश्यकता है। यह सिर्फ मेरा व्यक्तिपरक दृश्य है - क्या मुझे कुछ याद आ रहा है?
दिमित्री जैतसेव

1
सिर्फ इसलिए कि क्लाइंट की ओर से कुछ दिया जाता है इसका मतलब यह नहीं है कि यह तार्किक रूप से दृश्य का हिस्सा है। दृश्य में डेटा बाइंडिंग, निश्चित रूप से, लेकिन बैकबोन स्वयं एक एमवी * ढांचा है (एमवीसी का प्रकार, एमवीपी का प्रकार, बिल्कुल भी नहीं) और आपके क्लाइंट-साइड स्क्रिप्ट को तदनुसार आयोजित किया जाना चाहिए; अन्यथा, आप सिर्फ हैकिंग कर रहे हैं।
दोपहर 6:00

0

MVC में मैं कोशिश करता हूं और सुनिश्चित करता हूं कि मेरा नियंत्रक जितना संभव हो उतना "पतला" हो और यह भी कि मेरे मॉडल जितना संभव हो उतना गूंगा हो।

जिन लॉजिक और हेल्पर फंक्शंस की जरूरत होती है, उन्हें अलग-अलग स्टैंड हेल्पर क्लासेस में रखा जाता है। यह मेरे परीक्षण को बहुत आसान बनाता है और साथ ही (आप परीक्षण कर रहे हैं .. सही ??: D) परीक्षण नियंत्रकों के लिए बहुत कठिन है, किसी भी समय आप कोशिश करते हैं और नियंत्रक का एक उदाहरण बनाते हैं जो आपको परीक्षण के बारे में सोचना पड़ता है HTTP संदर्भ और फ़ेकिंग http यह और वह, और इसका दर्द, लेकिन इसका उद्देश्य पर एक दर्द। आपको उस सभी सामान की आवश्यकता है क्योंकि एक नियंत्रक HTTP और वेब से बहुत निकट से जुड़ा हुआ है। यह आपके वेब ऐप में प्रवेश बिंदु है।

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

हमने अपनी सभी डेटाबेस संस्थाओं (हमारे mvc मॉडल नहीं, हमारे वास्तविक db एंटिटीज़), हमारे स्टोरेज, हमारे हेल्पर क्लासेस और सेपरेट स्टैंड में हमारे तर्क को अकेले dll के साथ विकसित किया। हमारे पास केवल एक वेब साइट है, लेकिन हमने इसे वैसे भी किया।

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


2
MVC में मॉडल एकमात्र परत है जिसे गूंगा नहीं माना जाता है। यदि स्मार्ट मॉडल में नहीं हैं, और वे नियंत्रक में नहीं हैं, तो वे कहाँ हैं ... दृश्य में? नियंत्रकों को परीक्षण करना भी मुश्किल नहीं होना चाहिए; यूनिट परीक्षण की सुविधा के लिए डि और फेक / मोक्स का उपयोग करने की क्षमता अन्य रूपरेखाओं पर एमवीसी के ड्रा में से एक है। मेरे अधिकांश नियंत्रक परीक्षण 5 लाइनों के अंतर्गत हैं।
Aaronaught

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

मुझे लगता है कि इस उत्तर का मतलब अच्छी तरह से है लेकिन इसे गलत तरीके से कहा गया है .. या, शायद अलग शब्दावली।
सिमोन व्हाइटहेड

3
"हेल्पर" कक्षाएं एक वास्तुशिल्प तत्व नहीं हैं। वे या तो एम, वी, या सी का हिस्सा हैं। यदि आप सुनिश्चित नहीं हैं कि कौन से हैं, तो उन सहायकों में सामंजस्य की कमी है । शब्द "हेल्पर" भी वहीं "हैंडल", "डू", "परफॉर्म" और खूंखार मैनेजर के साथ रैंक करता है ।
Aaronaught

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

-2

दिमित्री ज़ैतसेव और अंतरिक्ष यात्री के महान जवाबों के अलावा, मुझे नहीं पता कि निम्न PHP के लिए भी मान्य है: आपको स्वचालित परीक्षण संभावनाओं की कमी के कारण निजी तरीकों से बचने की कोशिश करनी चाहिए।

हां, आप निजी तरीकों का परीक्षण करने के लिए मेटाप्रोग्रामिंग या निर्भरता इंजेक्शन का उपयोग कर सकते हैं, लेकिन आपको ऐसा नहीं करना चाहिए क्योंकि यह आपके कोड की पठनीयता पर भारी प्रभाव डालता है।

हमेशा याद रखें KISS सिद्धांत: यह सरल, बेवकूफ रखें।


5
यह निजी तरीकों से बचने का एक अच्छा कारण नहीं है, और एमवीसी वास्तुकला के साथ भी इसका कोई लेना-देना नहीं है। आप निजी तरीकों का परीक्षण करने की कोशिश नहीं करते हैं , उन्हें सार्वजनिक तरीकों पर परीक्षणों द्वारा कवर किया जाना चाहिए । यदि आप उन्हें कवर नहीं कर सकते हैं, तो यह संकेत है कि आपकी कक्षा बहुत जटिल है और इसे फिर से तैयार करने की आवश्यकता है; इसका मतलब यह नहीं है कि आपके पास निजी तरीके नहीं होने चाहिए या (मुझे पूरी उम्मीद है कि यह वास्तव में आपका मतलब नहीं है) इसके बजाय उन्हें सार्वजनिक होना चाहिए।
Aaronaught
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.