एमवीसी में आप अपने मॉडल कक्षाओं के संदर्भ कहां रखते हैं?

Question

मैं थोड़ी देर के लिए सोच रहा गया है, अलग-अलग लोगों से पूछ के बाद और उनमें से किसी को उपलब्ध कराने मैं एक "कम से कम एक सा ठोस जवाब" क्या कहेंगे बिना:

प्रश्न:

कहाँ, में एक आईफोन एप्लिकेशन को एक एप्लीकेशन को इसके मॉडल क्लासेस के संदर्भ रखना चाहिए (MVC दृष्टिकोण का उपयोग करके)?

आईफोन (और कोको) अनुप्रयोगों में हमारे पास "ऐप प्रतिनिधि" कहलाता है, जो मूल रूप से हमारे आवेदन को शुरू करता है और हमारे नियंत्रकों में प्रवेश करता है, यूआईटीच घटनाओं को भी संभालता है।

तो ऐप एक नियंत्रक प्रतिनिधि है? एक मॉडल वर्ग? दो में से कोई नहीं? मुझे नहीं लगता कि यह जानकर भी भ्रमित हो जाता है कि मॉडल संदर्भ कहां रखा जाए।

उदाहरण:

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

आप लोग ए और बी के संदर्भों को कहां स्टोर करेंगे? (ऐप प्रतिनिधि? नियंत्रक देखें? दोनों?)

यहां कई विकल्प हैं, लेकिन एक उदाहरण के रूप में, मैं वास्तव में जानना चाहूंगा कि आप इस एप्लिकेशन को एक साथ रखने के लिए एमवीसी का उपयोग कैसे करेंगे जो केवल एक दृश्य का उपयोग करता है।

Answer 1

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

• एक मॉडल
• एक दृश्य नियंत्रक (केवल दृश्य तर्क के लिए)
• एक नियंत्रक

तो उदाहरण के लिए, मेरे पास एक मॉडल फू और एक फू नियंत्रक है। मैं होगा:

• Foo.m (मॉडल)
• FooViewController.m (एक फू प्रदर्शित करता है)
• FooController.m (तर्क नियंत्रण)

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

Answer 2

परंपरागत रूप से नियंत्रक मॉडल बनाता है और फिर उस मॉडल के साथ देखें initialises पाने के लिए [[FooController sharedInstance] listOfFoos]: यदि आप एक सिंगलटन का उपयोग करते हैं, तो आप बस कुछ इस तरह कर सकते हैं। नियंत्रक फिर मॉडल में बदलावों को सुनता है और इस माध्यम से कार्यक्रम के प्रवाह को देख और समन्वयित करता है। यह मेरा सामान्य जवाब होगा, शायद अभ्यास में चीजें आईफोन विकास के लिए अलग होंगी।

Answer 3

जहां, एक आईफोन एप्लिकेशन में एक एप्लिकेशन को इसके मॉडल क्लासेस (एमवीसी दृष्टिकोण का उपयोग करके) के संदर्भ रखना चाहिए?

नियंत्रक परत मॉडल परत के संदर्भ रखती है।

तो ऐप एक नियंत्रक प्रतिनिधि है? एक मॉडल वर्ग? दो में से कोई नहीं?

ऐप प्रतिनिधि एक नियंत्रक है।

आप लोग ए और बी के संदर्भों को कहां स्टोर करेंगे?

ए और बी मॉडल कक्षाएं हैं जो आमतौर पर नियंत्रक परत द्वारा बनाई और स्वामित्व में बनाई जाएंगी।

मैं वास्तव में जानना चाहता हूं कि आप इस एप्लिकेशन को एक साथ रखने के लिए एमवीसी का उपयोग कैसे करेंगे जो केवल एक दृश्य का उपयोग करता है।

नियंत्रक परत का उद्देश्य मॉडल को अनुमति देना और परतों को स्वयं निहित होना है। मॉडल को नियंत्रक के बारे में कुछ भी नहीं पता होना चाहिए या परतों को देखना चाहिए। दृश्य नियंत्रक या मॉडल परतों के बारे में कुछ भी नहीं पता होना चाहिए। नियंत्रक का काम एक तरफ मॉडल के लिए डबल-एंडेड एडाप्टर होना चाहिए और दूसरे पर दृश्य होना चाहिए।

• UIApplication प्रतिनिधियों AppDelegate रहे हैं:

  मैं अपने उदाहरण एप्लिकेशन को इस तरह सेट किया जाएगा।

• तो अपने सर्वर वर्ग (ए) के संचालन सरल है:
  • AppDelegate बनाता है और सर्वर वर्ग ए के उदाहरण (रों) का मालिक है
• तो अपने सर्वर वर्ग के आपरेशन (ए) जटिल:
  • सर्वर को नियंत्रित करने के लिए एक समर्पित नियंत्रक वर्ग (सी) बनाएं।
  • ऐपडिलेगेट कक्षा सी के उदाहरण (ओं) का निर्माण और मालिक है (ए) के प्रत्येक उदाहरण के लिए (सी) का एक उदाहरण।
  • वर्ग सी में से प्रत्येक उदाहरण बनाता है और वर्ग ए
• AppDelegate बनाता है और अपने ViewController वर्ग का एक उदाहरण का मालिक है, जो भार और आपके विचार का मालिक का एक उदाहरण का मालिक है।

यह प्रश्न में स्पष्ट नहीं है कि कक्षा बी का उद्देश्य क्या है।

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

Answer 4

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

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

Answer 5

मुझे लगता है कि ज्यादातर मामलों में, ऐपडिलेगेट कुछ आधार कार्यक्षमता (जैसे एक पृष्ठभूमि छवि जिसे आप प्रत्येक नियंत्रक में लागू करना चाहते हैं) रखने के लिए एक अच्छी जगह प्रदान करते हैं, लेकिन आप अतिरिक्त नियंत्रक और मॉडल कोड कहीं और रखना चाहते हैं। एक NavController या rootController अक्सर आपके AppDelegate पर एक संपत्ति के रूप में रखा जाएगा।

तो, मैं कहूंगा कि यह "न तो" और "नियंत्रक" के बीच कहीं है, लेकिन "न तो" की तरफ झुक रहा है। निश्चित रूप से "मॉडल" नहीं!