MVCS - मॉडल व्यू कंट्रोलर स्टोर


35

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

संक्षेप में पुस्तक उद्धृत करने के लिए

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

तथा

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

मैं इस पैटर्न के बारे में और अधिक जानकारी प्राप्त करना चाहता था और यह देखने के लिए कि दूसरों को इसके बारे में क्या कहना है, लेकिन ऑनलाइन संदर्भों की खोज करते समय मैं केवल उसी पुस्तक को खोज सकता था (क्या पैटर्न शायद किसी अन्य नाम से जाना जाता है?)।

मेरे लिए लेखक का तर्क समझ में आता है, और यह नियमित एमवीसी पैटर्न के एक तार्किक विस्तार जैसा लगता है, लेकिन शायद ऐसा इसलिए है क्योंकि मुझे वास्तव में अभ्यास में एमवीसी पैटर्न के साथ बहुत अनुभव नहीं है (आईओएस विकास में अलग से मेरे पास है) प्रकार के साथ इस्तेमाल किया MVV की backbone.js (जो है, अगर आप इसे MVC पर विचार ))।

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


2
ActionScript में RobotLegs मतलब सेवा के लिए MVCS में "S" का उपयोग करता है। लेकिन यह अनिवार्य रूप से उसी तरह उपयोग किया जाता है। इसलिए इसका कम से कम एक उदाहरण है।
एमी ब्लेंकशिप

1
एमवीसी में, स्टोर आमतौर पर मॉडल का हिस्सा होता है। इसे डीएओ का हिस्सा कहा जाता है।
फ्लोरियन मार्गाइन

@FlorianMargaine नियंत्रक के विपरीत उपयोग कर रहे हैं (जो इस पुस्तक से निहित प्रतीत होता है (यह कहता है कि "MVC में अनुरोध तर्क नियंत्रक वस्तुओं की जिम्मेदारी है")? और क्या आप इसे अपनी स्वयं की परत पर ले जाने के लिए कोई स्पष्ट नकारात्मक पहलू देखते हैं? ?
जैक

जवाबों:


18

"स्टोर", MVCS डिजाइन पैटर्न के मामले में, स्टोरेज लॉजिक की ओर झुकाव करता है। IOS के मामले में, यह आमतौर पर एक कोर डेटा कार्यान्वयन है। यदि आप Xcode में एक कोर डेटा-समर्थित टेम्पलेट बनाते हैं, तो आप इस डिज़ाइन पैटर्न के "स्टोर" पहलू को देखेंगे जो कि AppDelegate वर्ग में है।

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

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

जहाँ तक इस डिज़ाइन पैटर्न के साथ स्पष्ट खामियाँ या समस्याएं हैं ... किसी भी डिज़ाइन पैटर्न के साथ, सबसे अधिक चमकदार समस्या यह सुनिश्चित कर रही है कि आपने अपनी परियोजना को इस तरह से सेट किया है जो प्रतिमान के साथ रहती है। विशेष रूप से एक डिजाइन पैटर्न जो आपके लिए नया है, यह कभी-कभी सबसे कठिन हिस्सा हो सकता है। अपने "स्टोर" लॉजिक को अपनी ही कक्षा में तोड़ने का लाभ यह है कि यह कोड मेंटेनेंस को बहुत आसान बना देता है।


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

हैलो @jimstone, मैं स्टोर तर्क के बारे में थोड़ा भ्रमित हूं। क्या आप मदद कर सकते हैं? मान लीजिए मेरे पास 5 मॉडल हैं, प्रत्येक के लिए मेरे पास 2 कक्षाएं हैं, एक जो नेटवर्किंग और वस्तुओं के अन्य कैशिंग (कोर डेटा और सामान) को बनाए रखता है। अब मेरे पास प्रत्येक मॉडल के लिए अलग स्टोर क्लास होना चाहिए, जो नेटवर्किंग + कैश फ़ंक्शन कॉल या एकल स्टोर वर्ग वाले फ़ंक्शन को कॉल करता है, जिसमें प्रत्येक मॉडल के लिए सभी नेटवर्किंग + कैश फ़ंक्शन कॉल होते हैं, इसलिए नियंत्रक हमेशा डेटा के लिए एकल फ़ाइल तक पहुंचते हैं।
उल्का

18

इस संदर्भ में 'स्टोर' एक रिपॉजिटरी या सेवा की तरह लगता है । उस मामले में, यह एक अत्यंत सामान्य पैटर्न है। आपके कार्यान्वयन और समस्या डोमेन के साथ दोष / समस्याएं अलग-अलग होंगी।

एक सामान्य स्तर पर, ऐसा लगता है कि पुस्तक 'स्टोर' का उपयोग व्यापार तर्क के स्तर + डेटा पुनर्प्राप्ति तर्क के स्तर का प्रतिनिधित्व करने के लिए करती है जो डेटा के एक सेट को संभालती है जो आपके एप्लिकेशन का हिस्सा हो सकती है या नहीं।

उदाहरण के लिए, ट्विटर एपी को 'स्टोर' में लपेटना उस तर्क को समझने का एक अच्छा तरीका है।

आगे MVC की परिभाषा का
उपयोग करते हुए (जो मुझे लगता है कि बहुत सुंदर है), 'स्टोर' वास्तव में मॉडल का सबसेट है। यह एमवीसी के लिए एक विस्तार है या क्या यह डेटा पुनर्प्राप्ति पैटर्न है या नहीं, के बीच का परिसीमन बहुत उपयोगी नहीं है। वे अंत में एक ही कोड की तरह दिखते हैं।

नीचे की रेखा, मुझे लगता है कि वे जो सलाह देते हैं, उसके अनुसार आप ठीक लगेंगे।


1
आपके द्वारा प्रदान किए गए लिंक के माध्यम से पढ़ना, यह समान ध्वनि करता है, सिवाय इसके कि इसका उपयोग एमवीसी पैटर्न के विस्तार के रूप में किया जा रहा है।
जैक

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