गैर-प्रोग्रामर को MVC समझाएं [बंद]


31

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

MVC पृथक्करण वे क्या पूछ सकते हैं? यह क्यों आवश्यक है वे पूछ सकते हैं?

इस तरह एक काफी तकनीकी जवाब पढ़ने के बाद: वास्तव में एमवीसी क्या है? , मैं पूरी तरह से संतुष्ट नहीं हूं, क्योंकि मैं गैर-प्रोग्रामर से बात करूंगा। वे अपना सिर हिला सकते हैं, लेकिन वे शायद यह नहीं समझ पाएंगे कि यह क्या है और इसकी आवश्यकता क्यों है।

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

तो अगली बार जब आप एमवीसी को एक गैर-प्रोग्रामर को समझा रहे हैं, जिसकी बिक्री और पृष्ठभूमि में उदाहरण हैं, तो आप उन्हें क्या कहेंगे?



12
बताएं कि यह "सर्वश्रेष्ठ अभ्यास" है और वे खुश होंगे।
जोहान

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

2
आप कैसे समझाएंगे, अगर आप पूरी तरह से समझ नहीं पाते हैं कि यह क्या है?
B:00овиЈ

मुझे लगता है कि संभवत: औद्योगिक क्रांति के विनिमेय भागों के पहलू के साथ एक सादृश्य बनाया जाना चाहिए ... निश्चित रूप से वे इस बारे में चिंता किए बिना 1 / 4-20 छेद को ड्रिल और टैप करने में सक्षम होने के लाभों को समझ सकते हैं या नहीं बोल्ट फिट होगा।
जे ...

जवाबों:


70

आप MVC की व्याख्या नहीं करते हैं।

आप जो करते हैं वह समझाता है कि यह कोडबेस का पुनर्गठन है।

एक पुनर्गठन जो कोडबेस को सरल बनाता है और इसलिए कम बग के साथ डेवलपर्स को बग रिपोर्ट और सुविधा अनुरोधों में तेजी से और बेहतर बदलाव करने में सक्षम बनाता है।

उन्हें तकनीकी विवरणों को जानने की आवश्यकता नहीं है, बस यह क्यों किया गया था, इसे करने से क्या हासिल हुआ था और व्यवसाय कैसे लाभान्वित हुआ।

दूसरे शब्दों में - उन्हें अपनी भाषा बोलें।


13
IOW MVC के पुनर्गठन की आवश्यकता की व्याख्या करता है (यह बहुत अच्छा है: उनकी भाषा उन पर बोलें )
वुल्फ

4
अक्सर उन मामलों का उल्लेख करना मददगार होता है जहां बग-फिक्स और सुविधा अनुरोध तेजी से (सस्ते) होते अगर कोड-बेस में चिंताओं का उपयुक्त पृथक्करण होता।
एरिक विल्सन Eric

14
मुझे लगता है कि यह अगली छलांग लगाने के लिए उपयोगी होगा और सुझाव दिया जाएगा कि बोली जाने वाली भाषा $ £ ƒ € .руб है। यदि आप इसे किसी गैर-प्रोग्रामर को समझा रहे हैं, तो यह संभवतः व्यावसायिक संदर्भ में है और यह बहुत संभावना है कि यह "पैसा कहाँ जा रहा है" के लिए उबलता है?
जोएल एथरटन '

यह उन चीजों की तुलना करने में मदद कर सकता है जो वे जानते हैं। "हम इसे व्यापक रूप से अपनाए गए संगठनात्मक सिद्धांतों से मिलान करने के लिए पुनर्गठन कर रहे हैं, जिस तरह के सम्मेलनों को लेखा समुदाय ने सुलझा लिया है।"
नातान

41

जबकि मैंने ओड के जवाब के सार का समर्थन किया है , कि आपको तकनीकी प्रबंधकों को "उनकी भाषा में," मुझे उनकी योग्यता के बारे में तकनीकी जानकारी समझानी चाहिए "उन्हें तकनीकी विवरणों को जानने की आवश्यकता नहीं है, बस ऐसा क्यों किया गया।"

यदि आप विभाग प्रमुखों के साथ एक परियोजना या निवेश की समीक्षा बैठक में हैं, और आप घोषणा करते हैं "यह वही है जो हम कर रहे हैं," वे "उम्म ... पूछना चाहते हैं? ऐसा क्यों होता है? यह समय और ऊर्जा के बड़े निवेश की तरह लगता है। क्या आप हमें थोड़ा और समझ दे सकते हैं कि आप क्या कर रहे हैं और क्यों? " यह एक उचित सवाल लगता है। आप "ठीक है ... यह जटिल है" की स्थिति में नहीं पकड़ा जाना चाहते हैं। या "नहीं, मैं वास्तव में इसकी व्याख्या नहीं कर सकता।" या "अपने बारे में चिंता न करें।" जितने वरिष्ठ कर्मचारी आप के लिए परियोजना की समीक्षा कर रहे हैं, उतनी ही कम संभावना है कि वे "यह सिर्फ सामान है जो मैं अच्छी तरह से समझा नहीं सकता" उड़ सकता हूं। बेहतर होगा यदि आप दूसरों को सहज महसूस कराने के लिए कम से कम एक स्तर गहरा जा सकते हैं कि 1) आप जानते हैं कि आप क्या हैं '

तो, अपने हिप पॉकेट में एमवीसी का एक स्केच रखें, जाने के लिए तैयार। कुछ इस तरह:

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

यहां तक ​​कि अगर वे इसके अंत में एमवीसी को पूरी तरह से नहीं समझते हैं, और भले ही आपको इसे सरल बनाने के लिए ओवर-सरलीकृत करना था ("एक ऑमलेट बनाने के लिए कुछ अंडे तोड़ दें"), मैं दांव लगाता हूं कि आप इसे और अधिक आरामदायक पाएंगे "मैं इसे समझा नहीं सकता" या "आप इसे समझने के लिए योग्य नहीं हैं" वरिष्ठ प्रबंधकों से कहने के लिए एक स्पष्टीकरण तैयार है।


4
So, have a sketch of MVC in your hip pocket, ready to go.- या शायद एक पीपी प्रस्तुति ;-) उपयोगकर्ता के रूप में "उनकी भाषा"?
वुल्फ

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

2
@ टोबिया यही बात है कि Microsoft एक मॉडल को बुलाता है। "मॉडल" उस सिस्टम का प्रस्तुतिकरण-अज्ञेय कंप्यूटर मॉडल है जिसके साथ उपयोगकर्ता इंटरैक्ट करता है, इसलिए बहुत अधिक वह सब कुछ जो दृश्य और नियंत्रक का हिस्सा नहीं है।
डोभाल

@ डोभाल माइक्रोसॉफ्ट की व्याख्या हो सकती है, लेकिन यह एमवीसी की व्यापकता का प्रतिबंध है। रूबी ऑन रेल्स, Django, या ग्रेल्स जैसे फुर्तीले MVC फ्रेमवर्क पर एक नज़र डालें, जो कि मेरा मतलब है। मैंने इस सामान्य गलतफहमी को कवर करने के लिए अपने उत्तर का विस्तार किया है।
टोबिया

3
मूल स्मॉलटॉक एमवीसी पैटर्न में, स्क्रीन पर प्रत्येक नियंत्रण का अपना मॉडल, दृश्य और नियंत्रक था। चलो बहाना नहीं है कि एमवीसी की एक ही परिभाषा है जिस पर हर कोई सहमत है। सौभाग्य से, उसे केवल यह समझाने की ज़रूरत है कि वह क्या कर रहा है।
रेमकोगर्लिच

9

सॉफ्टवेयर में परिवर्तन करने के लचीलेपन में सुधार करने के लिए

प्रबंधक अंतिम परिणाम में रुचि रखते हैं। कम तकनीकी वे कम संभावना है कि वे चिंतित हैं कि आप वहां कैसे पहुंचे। एमवीसी बहुत आम, लोकप्रिय और सिद्ध है।

जब भविष्य में परिवर्तन अनुरोध किए जाते हैं, तो आप प्रबंधन को बता सकते हैं कि उन्हें आसान और तेज़ बनाया जा सकता है। यह सुनना हर किसी को पसंद है।

यह एक सामान्य रणनीति है, इसलिए नए डेवलपर्स को काम पर रखने से समस्या पेश नहीं होनी चाहिए। वास्तव में, आप बेहतर डेवलपर्स को आकर्षित कर सकते हैं जो मजबूत प्रस्तावक हैं।

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


9
  • मॉडल - तार / बिजली
  • देखें - प्रकाश स्थिरता
  • नियंत्रक - लाइट स्विच

घटकों (प्रकाश स्थिरता, प्रकाश स्विच / डिमर) को स्विच करने के लिए अपेक्षाकृत आसान है। शायद इतना नहीं कि तारों, लेकिन अभी भी अन्य घटकों को प्रभावित किए बिना किया जा सकता है। हर किसी को यह कल्पना करने में सक्षम होना चाहिए कि आपके सिर, यहां तक ​​कि विपणन / बिक्री के प्रकार भी। (स्पष्ट जुदाई, आदि)

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

MVC कोड बेस के लिए एक पैटर्न लागू कर रहा है, जो कम त्रुटियों के साथ तेजी से और आसानी से हो सकने वाली चीज़ में गड़बड़ी (लेकिन काम कर रहा है) को गड़बड़ कर देता है।


हम्म ... कि सादृश्य वास्तव में "स्पॉट हिट नहीं" IMHO।
देवसोलर

लेकिन किसी तरह की उपमा देने के बारे में पूरा विचार यह है। मैंने भी कुछ ऐसा ही लिखा होगा। आमतौर पर कार या पैसे से जुड़ी कोई चीज काफी अच्छी तरह से काम करती है ... :-)
जेन्स जी

वास्तव में जिन लोगों को उत्थान करना चाहिए, वे गैर-प्रोग्रामर हैं। मुझे लगता है कि साइट के अधिकांश उपयोगकर्ता प्रोग्रामर हैं! :)
जॉन रेन्नोर

3

एक आसान तरीका है समझने के लिए MVC: मॉडल डेटा है , दृश्य स्क्रीन पर खिड़की है , और नियंत्रक दोनों के बीच गोंद है

अब तक का सबसे अच्छा रूब्रिक: "हमें स्मार्ट मॉडल्स, थिन कंट्रोलर्स और DUMB व्यूज की आवश्यकता है"

अन्य सॉफ्टवेयर डिजाइन पैटर्न के साथ, MVC एक समस्या के " समाधान के मूल " को व्यक्त करता है, जबकि इसे प्रत्येक सिस्टम के लिए अनुकूलित किया जा सकता है। इसे एक विशिष्ट कार्यान्वयन के बजाय एक अवधारणा के रूप में देखा जाता है। अवधारणा के कई कार्यान्वयन हैं।

सभी MVC वेरिएंट घटकों के एक ही विभाजन का उपयोग करते हैं, लेकिन आमतौर पर वे अलग-अलग होते हैं कि कैसे उन घटकों को आपस में मिलाते हैं।

यहाँ छवि विवरण दर्ज करें

आप में से जो जागरूक नहीं हैं, उनके लिए मूल रूप से MVC को 1979 में Trygve Reenskaug द्वारा स्मॉलटाक के साथ उपयोग के लिए एक डिज़ाइन पैटर्न के रूप में वर्णित किया गया था । उनका पेपर "एप्लिकेशन प्रोग्रामिंग इन स्मॉलटाकल -80: मॉडल-व्यू-कंट्रोलर का उपयोग कैसे करें" शीर्षक के तहत प्रकाशित किया गया था और अधिकांश भविष्य के एमवीसी कार्यान्वयनों के लिए आधार बनाया गया था।


3

मैं आधे-अधूरे से सहमत हूं - अपने गैर-तकनीकी साथियों और प्रबंधकों को यह समझाने के लिए कि आप क्या कर रहे हैं, महत्वपूर्ण और उपयोगी है, बिना बारीकियों को समझे, यह एक आवश्यक कौशल है जिसे आप विकसित करने में बुद्धिमान होंगे।

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

एक तरफ, चलो इस सवाल का जवाब दें:

मुझे उन उपमाओं का उपयोग करना उपयोगी लगता है जो व्यवसाय के लोग समझते हैं। एमवीसी के लिए, मैं इसे एक व्यवसाय के रूप में वर्णित करता हूं।

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

इस सादृश्य के साथ इसे समझाने का लाभ यह है कि एक अच्छा प्रबंधक इस तरह से चिंताओं को अलग करने में समझदारी को देखेगा, और यह तय कर सकता है कि उन्हें अधिक नियंत्रक जैसा होना चाहिए, और भविष्य में विवरण में शामिल नहीं होना चाहिए!

उम्मीद है कि "क्या" जवाब देंगे - "क्यों" इस सादृश्य के साथ भी आसान है:

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

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

** अस्वीकरण - यदि आपकी कंपनी खराब संगठित है, तो वे इससे नाराज हो सकते हैं। उस मामले में, आपको एक और सादृश्य की आवश्यकता होगी। आपको एक अलग नौकरी की भी आवश्यकता हो सकती है।


यदि ओपी की कंपनी खराब रूप से संगठित है, तो मैं उसे सामान्य आर्थिक प्रगति की तर्ज पर "काम के बंटवारे" के बारे में बात करने का सुझाव देता हूं, जैसे शिकारी / इकट्ठा करने वाले सॉफ्टवेयर डेवलपर्स जैसे विशेष श्रमिकों में बदल जाते हैं :)
logc

अच्छा विवरण - उत्कृष्ट अस्वीकरण।
नागरिककॉन्ग

2

MVC के लाभ मुख्य रूप से चिंताओं के अलगाव में हैं:

यह लोगों को इस बात पर ध्यान केंद्रित करने देता है कि वे सबसे अच्छा क्या करते हैं।

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

इसकी लागत कम होती है क्योंकि इंटरवेटिड सिस्टम को इन सभी क्षेत्रों में या तो विशेषज्ञों की आवश्यकता होती है, या जब एक क्षेत्र में बदलाव दूसरों को प्रभावित करता है, तो आपको समस्या होने की अधिक संभावना होती है।

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


4
मैं डेटाबेस के साथ MVC के मॉडल की बराबरी नहीं करूंगा, और न ही MVC के उपयोगकर्ता इनपुट के साथ।
तोबिया

1
@ टोबिया हाँ, लेकिन उस की बारीकियों को एक गैर-तकनीकी व्यक्ति पर खो दिया जाएगा। इसे बिंदु मिलता है
B2K

@ टोबिया ने इस पर पुनर्विचार करते हुए समायोजित विवरण को अधिक सटीक बताया। आपकी टिप्पणियों के लिए आभार।
B2K

1

मैं उन्हें बताऊंगा कि MVC मेरी चिंताओं को अलग करता है।

मेरी पहली चिंता कोड लॉजिक है - वेबसाइट के कार्यों को करने के लिए पर्दे के पीछे जो मैं करता हूं, वे वे कार्य करते हैं जो वे चाहते हैं।

मेरी दूसरी चिंता व्यावसायिक तर्क है - वे (उपयोगकर्ता) क्या चाहते हैं कि आवेदन करना चाहिए।

मेरी तीसरी चिंता यह है कि साइट कैसी दिखती है - वे जिस पेज पर जाते हैं, वह वही करता है जो वे चाहते हैं।

(मैं उन्हें यह अगला भाग नहीं बताऊंगा) इसलिए, क्रम में, मेरा स्पष्टीकरण मॉडल, नियंत्रक और दृश्य के लिए था।


1

फायदे बताइए

मैं व्यावसायिक लाभों के संदर्भ में एमवीसी को समझाऊंगा। आपके प्रबंधक इसे समझने में सक्षम होंगे, और बोर्ड पर मिलेंगे यदि फायदे आश्वस्त हैं।

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

आदर्श

प्रत्येक मॉडल सभी प्रकार के व्यावसायिक तर्क के साथ-साथ एक ही प्रकार की व्यावसायिक जानकारी, उदाहरण के लिए, ग्राहक रिकॉर्ड या उत्पाद को इनकैप्सुलेट करता है।

इसे अलग करने से आप अपने व्यवसाय के तर्क को अपने आवेदन के अन्य हिस्सों से आसानी से अलग कर सकते हैं।

आप अतिरिक्त मॉडल जोड़कर भी आसानी से एप्लिकेशन का विस्तार कर सकते हैं, यह बहुत मॉड्यूलर और साफ है।

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

दृश्य

अपने दृष्टिकोण को अलग करना आपको अंतर्निहित बैक एंड को तोड़ने के बिना आसानी से अपने सामने के छोर को अपडेट करने की अनुमति देता है।

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

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

नियंत्रक

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

अन्य फायदे

यह एक सामान्य पैटर्न है। अन्य डेवलपर्स आपके कोड को समझने और उस पर काम करने में सक्षम होंगे। यदि आप वर्षों बाद अपने कोड पर लौटते हैं, तो आप संभवतः इसे समझने और बदलाव करने में सक्षम होंगे। आपका कोड भविष्य के डेवलपर के लिए एक और विरासत सिरदर्द बनने की संभावना कम होगी।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.