एमवीसी डिजाइन पैटर्न। इसे कैसे फिट करता है?

Question

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

Answer 1

एक दृश्य का काम डेटा प्रदर्शित करना और घटनाओं की रिपोर्ट करना है।

नियंत्रक का काम विचारों और मॉडलों के बीच संचार समन्वय करना है।

डेटा का काम स्टोर डेटा है और उस डेटा के आसपास व्यावसायिक तर्क प्रदान करने के लिए भी है।

आप से पूछा:

मुझे समझने में कठिनाई आ रही है थे "दृश्य" में फिट

अपने उदाहरण में, UIPickerView दृश्य है।।

आईओएस/ओएसएक्स में, एक व्यू कंट्रोलर सिर्फ एमवीसी का नियंत्रक है। ऐसा ही होता है कि एक व्यू कंट्रोलर में एक खाली दृश्य कंटेनर भी होता है जिसमें आप अन्य सभी विचार जोड़ सकते हैं। लेकिन अभी भी आईओएस/ओएसएक्स में एमवीसी का एक स्पष्ट अलगाव है।

UIButton, UIPickerView, UITableView, आदि जैसे सभी वर्ग दृश्य का प्रतिनिधित्व करते हैं। एक व्यू कंट्रोलर का काम डेटा मॉडल से डेटा के साथ उन विचारों को प्रदान करना है और साथ ही उन विचारों की घटनाओं का जवाब देना है जो आपको अन्य विचारों और डेटा मॉडल को अपडेट करने का मौका देते हैं।

आप यह भी कहा:

हालांकि हर दृश्य की आवश्यकता है कि एक दृश्य नियंत्रक को देखने के लिए सभी आउटलेट्स ऊपर तार से जुड़ा हो। मुझे लगता है कि व्यू और व्यू कंट्रोलर को अलग रखने का तरीका कैसा लगता है?

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

आप से पूछा:

कैसे या क्यों मैं इस दृश्य कक्षा मेरी देखें नियंत्रक वर्ग से अलग कर दिया है करने के लिए चाहेगा?

UITableViewController पर देखें। यह अलगाव का एक स्पष्ट उदाहरण है लेकिन यह काफी साफ पैकेज में प्रदान किया जाता है। आपके पास वास्तव में एक अलग UITableView वर्ग है जो दृश्य है। यह दृश्य दृश्य को प्रस्तुत करने और उपयोगकर्ता बातचीत को एकत्रित करने के लिए ज़िम्मेदार है। यह वास्तविक तालिका दृश्य नियंत्रक है जो दृश्य को डेटा प्रदान करता है और उपयोगकर्ता ईवेंट को दृश्य से संभालता है।

आप किसी भी दृश्य में UITableView विचार जोड़ सकते हैं। यह एक पूरी तरह से पुन: प्रयोज्य दृश्य घटक है। प्रत्येक कंट्रोलर जिसे आप टेबल व्यू पर लगाते हैं, कोई उचित डेटा प्रदान कर सकते हैं और उपयोगकर्ता इंटरैक्शन को सही तरीके से संभाल सकते हैं।

Answer 2

ठीक है, मैं चीजों को थोड़ा सा हल करने की कोशिश करूंगा।

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

अब क्यों डिजाइन यह क्या है है की मेरी nooby स्पष्टीकरण:

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

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

Answer 3

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

मॉडल आमतौर पर "कुछ करें" परत माना जाता है। इसमें व्यापार तर्क और डेटा तर्क है। आपका मॉडल एफएटी होना चाहिए, स्किननी नहीं, जिसका अर्थ है कि मॉडल में आपका बहुत कोड होना चाहिए।

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

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

<div>@foreach person in Model.Users{ 
    <p>@person.FullName</p> 
} 
</div> 

तो आप देख सकते देखें कुछ "प्रदर्शन तर्क" हो सकता है (जैसे, पाश कर सकते हैं और पूर्ण नाम प्राप्त करें) लेकिन यह वास्तव में आपके पास होना चाहिए।

यहां एक त्वरित स्लाइड शो भी शामिल क्यों की अपनी आरंभिक स्पष्टीकरण "मॉडल डेटा रखती है, नियंत्रक तर्क रखती है" MVC, के बारे में अधिक बताते है वास्तव में सच नहीं है: http://www.slideshare.net/damiansromek/thin-controllers-fat-models-proper-code-structure-for-mvc

MVC डिजाइन पैटर्न शामिल नहीं है "व्यू कंट्रोलर" नामक कुछ भी, जो कहीं और से आ रहा है।

Answer 4

दरअसल जो आप समझते हैं वह पूरी तरह से गलत है।

एमवीसी डिजाइन पैटर्न के पीछे मूल सिद्धांत Separation of Concerns है। आप प्रस्तुति परत से मॉडल परत अलग करते हैं और (प्रस्तुति परत में) आप नियंत्रक से अलग विचार देखते हैं।

• मॉडल परत व्यापार तर्क के सभी शामिल हैं:
  वहाँ पार्स की

  प्रत्येक एक अलग जिम्मेदारी है। इसमें भंडारण, डोमेन तर्क और अनुप्रयोग तर्क के साथ बातचीत शामिल है।

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

---

वहाँ है कि लोगों को बनाए रखने के लिए करते हैं MVC के बारे में गलत धारणा है के एक बहुत हैं। उदाहरण के लिए:

1. कुछ लोग जोर देंगे कि विचार गूंगा टेम्पलेट्स हैं। वो नहीं हैं।

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

2. कोई "मॉडल" नहीं हैं। मॉडल एक परत है, जिसमें कक्षाओं के कई अलग-अलग समूह होते हैं, प्रत्येक विशिष्ट कार्य के साथ। वैसे ही प्रस्तुति परत

3. नियंत्रकों के लिए मॉडल परत से डेटा भेजने के लिए कोई "प्रेजेंटेशन" ऑब्जेक्ट नहीं है। नियंत्रक केवल त्रिभुज के अन्य हिस्सों की स्थिति को बदलता है। दृश्य उदाहरण स्वयं मॉडल मॉडल से जो चाहिए उसे अनुरोध करते हैं।