एमवीसी डिज़ाइन पैटर्न

Question

के लिए आईओएस प्रोजेक्ट व्यवस्थित करना मैं आईफोन के लिए एक मल्टीव्यू ऐप पर काम कर रहा हूं और वर्तमान में मेरे विचार (दृश्य) सेट अप हैं और उनके संक्रमण (CONTROLLER?) अच्छी तरह से काम कर रहे हैं। अब मैं वास्तविक प्रोग्राम डेटा (मॉडल) के लिए ऑब्जेक्ट्स जोड़ना चाहता हूं।

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

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

बहुत धन्यवाद और मेरी एमवीसी नोबरी क्षमा करें।

Answer 1

कालेब समस्या के बारे में सोचने के बारे में एक अच्छा परिचय और अवलोकन देता है। वास्तविक ऑडियो डेटा के आयोजन के लिए जिम्मेदार -

• क्लिप (एम): अपने विशेष मामले में, यहाँ टुकड़े आप अपने विवरण दे दिया है हो सकता है होता हैं।यह जानेगा कि डेटा की व्याख्या कैसे करें और इसके बारे में दी गई जानकारी, लेकिन यह वास्तव में कुछ भी नहीं खेलती है।

• प्लेयर (वी) - वास्तव में वक्ताओं पर एक क्लिप चलाता है। हां, यह एक प्रकार का एमवीसी में देखें। ऑडियो सिर्फ एक और प्रकार की प्रस्तुति है। उस ने कहा, आप इसे कभी भी "प्लेयरव्यू" नहीं कहेंगे क्योंकि यह सुझाव देगा कि यह UIView का उप-वर्ग था।

• प्लेयर व्यू (वी) - प्लेयर का एक स्क्रीन प्रतिनिधित्व। क्लिप के बारे में कुछ भी नहीं जानता है।

• ClipManager (सी) - एक उद्देश्य यह है कि प्रणाली में सभी क्लिप का ट्रैक रखने और, नेटवर्क से उन्हें प्राप्त करने में कठिनाई जोड़ने और उन्हें कैश करने के लिए दूर करने का प्रबंधन करेगा, आदि

• PlayerViewController (सी) - क्लिपमैनेजर से एक क्लिप पुनर्प्राप्त करता है, और इसे प्रदर्शित करने और चलाने के लिए प्लेयर और प्लेयरव्यू को समन्वयित करता है, साथ ही साथ किसी अन्य UI तत्व (जैसे "बैक बटन" या जैसा)।

यह केवल एक उदाहरण है कि आप कुछ सैद्धांतिक ऑडियो प्लेयर ऐप के लिए इसे कैसे तोड़ सकते हैं। ऐसा करने के लिए कई सही एमवीसी तरीके हैं, लेकिन इसके बारे में सोचने का यह एक तरीका है।

Answer 2

लॉर्ड जॉन वर्फिन (और, मुझे यकीन है कि, उसके सामने कोई व्यक्ति) ने कहा: "चरित्र वह है जो आप अंधेरे में हैं।" खैर, एक मॉडल यह है कि जब कोई भी नहीं देख रहा है तो यह एक एप्लिकेशन है - यह डेटा और तर्क है जो यह परिभाषित करता है कि ऐप कैसे स्क्रीन पर प्रस्तुत किए जाने के बावजूद व्यवहार करता है।

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

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

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

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

मुझे उम्मीद है कि इससे मदद मिलती है।