एक दृश्य और एक मॉडल को संवाद करना चाहिए या नहीं?

Question

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

आप इन दो विपरीत बिंदुओं की व्याख्या कैसे करते हैं?

Answer 1

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

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

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

Comments

एक मॉडल को देखने के मॉडल के मानचित्रण के थकाऊ पहलुओं के संबंध में यह ध्यान दिया जाना चाहिए कि ऐसे उपकरण हैं जो उपलब्ध हैं जो मानचित्रण दर्द को कम कर सकते हैं। ईजी: (.NET ऑटोमैपर) (जेएवीए मॉडलमैपर)

— जेसी

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

— maple_shaft

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

— रेमंड सॉल्टरी

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

— मफिन मैन

Answer 2

वेब पर, हर कोई अपने decoupling MVC को कॉल करता है।

कुछ प्रौद्योगिकियां, जैसे C #, MVVM का उपयोग करती हैं क्योंकि व्यू और किसी अन्य के बीच कोई लिंक नहीं है, सब कुछ सर्विस लोकेटर से होकर गुजरता है, चर को विभाजित करता है।

शुद्ध एमवीसी पर, व्यू सीधे मॉडल और इसके विपरीत बातचीत करता है। नियंत्रक केवल तब होता है जब कोई परिवर्तन होता है।

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

आपको यहां एक बेहतर व्याख्या दिखाई देगी: http://www.garfieldtech.com/blog/mvc-vs-pac

Answer 3

मेरे लिए, एक वास्तुकला का मूल लक्ष्य यह है कि यह भविष्य के प्रयासों को फिर से तैयार करने में बाधा न डाले। आमतौर पर, मॉडल इस आवश्यकता के साथ सीधे बातचीत करते हैं, और ऐसा नहीं होने पर यह अपेक्षाकृत स्पष्ट है।

जब एक मॉडल के साथ एक दृश्य बहुत अंतरंग होता जा रहा है, तो एक ViewModel एक सुंदर चीज हो सकती है, लेकिन यह आमतौर पर मेरे लिए मामला है कि जिन उदाहरणों के लिए इसे बुलाया गया है वे अल्पसंख्यक हैं।

Answer 4

में MVC , पॉल Hegarty गलत है। नियंत्रक उपयोगकर्ता घटनाओं के बारे में है, न कि मॉडल-टू-व्यू संचार। शास्त्रीय एमवीसी में , दृश्य (ओं) को मॉडल (ऑब्जर्वर पैटर्न) देखें।

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

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

Comments

आज (2014 की शुरुआत में), मुझे (मेरे नोड और कोणीय स्टैक के साथ) "क्लाइंट" एमवीसी और "सर्वर" एमवीसी पर यह अंतर बहुत प्रासंगिक और किसी तरह ज्ञानवर्धक लगता है। (

— साभार

Answer 5

चूंकि आप उन स्टैनफोर्ड व्याख्यान में सामग्री के बारे में विशेष रूप से पूछ रहे हैं, यह हेगार्टी के रुख के बारे में दो बातों पर विचार करने के लायक है:

1. जैसा कि आपने उल्लेख किया है, वह एक एल-स्तरीय कंप्यूटर विज्ञान पाठ्यक्रम पढ़ा रहा है। उनके व्याख्यानों में बहुत सारे स्थान हैं जहाँ वह सरल करते हैं, विवरणों पर विस्तार करते हैं, या कहते हैं "बस इस तरह से करें", जैसा कि शायद मूल बातें सिखाते समय आपको करना होगा, अर्थात आपको उन्हें तोड़ने से पहले नियमों को मास्टर करना होगा।
2. आईओएस एसडीके के साथ मेरा अनुभव यह है कि जहां यह व्यू और मॉडल के बीच सख्त अलगाव को लागू नहीं करता है , यह उस पैटर्न की ओर बहुत अधिक सक्षम है। विशेष रूप से iOS ऐप लिखते समय, मॉडल-व्यू सेपरेशन का पालन करने से आपको कोड लिखने में मदद मिलती है जो फ्रेमवर्क की अपेक्षाओं के अनुरूप है। मैं अन्य प्लेटफार्मों पर या सामान्य रूप से विकास के लिए हेगार्टी के बयानों को सामान्य बनाने में संकोच करूंगा।

Answer 6

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

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

इस मामले में भी नियंत्रक को देखने के साथ काफी जोड़ा जाता है और सादगी के लिए मैं हमेशा उन्हें स्पष्ट रूप से अलग नहीं करता।

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

Answer 7

मेरा मानना ​​है कि इसके लिए कठिन और तेज नियम नहीं है, यह पूरी तरह से आपकी आवश्यकताओं पर निर्भर करता है।

आपको अलग-अलग मान्यताओं वाले लोग मिलेंगे। आर्किटेक्चर बेहतर समाधान डिजाइन करने में मदद करने के लिए अवधारणाएं हैं।

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

इसके अलावा व्यावसायिक तर्क को एप्लिकेशन लॉजिक (इसे नियंत्रक पर रखें) और डोमेन लॉगिन (मॉडल पर रखें) में विभाजित करने की संभावना है।

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

Answer 8

मैं मॉडल-व्यू संचार के लिए डीटीओ का उपयोग करता हूं।

उदाहरण के लिए:

• उपयोगकर्ता अद्यतन फ़ॉर्म भरता है (देखें)
• उपयोगकर्ता प्रपत्र भेजता है
• कंट्रोलर UserUpdateDTO को डेटा बनाता है
  • DTO और UserModel POJO हैं, लेकिन DTO का कोई आईडी और उपयोगकर्ता नाम नहीं है क्योंकि हम उपयोगकर्ता नाम अपडेट नहीं कर सकते हैं।
  • एक अन्य अंतर यह है कि मॉडल वर्ग के संबंध और संबंध हैं लेकिन डीटीओ केवल डेटा संग्रहीत करता है और हम इसमें JSR 303 सत्यापनकर्ता जोड़ सकते हैं
• नियंत्रकों का कहना है कि इसे बचाने के लिए सेवा की परत है
• डेटा को बनाए रखने के लिए सेवा परत DAO परत को कहती है

Answer 9

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

मैं इसे और अधिक संगठनात्मक मुद्दे के रूप में देखता हूं जो कुछ भी हो।

Answer 10

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

जैसा कि हमें अपने ऐप्स को UI / UX या मॉडल या कुछ समय दोनों में अपडेट रखने की आवश्यकता हो सकती है, यह मॉडल और दृश्य के बीच मोड निर्भरता कोड का उत्पादन नहीं करना चाहिए। यदि आप अपने ऐप की प्रस्तुति परत को बदलना चाहते हैं, तो आप बस जाएं और इसे बदल दें फिर भी आप उसी मॉडल का पुन: उपयोग कर सकते हैं और इसके विपरीत किया जा सकता है।

हालाँकि, मैं मानता हूं कि iOS में MVC इसमें कई तरह के लॉजिक्स के साथ विशाल व्यू-कॉन्ट्रॉलर्स का उत्पादन करता है और इसके अलावा हर तरह के सामान को संभालता है। छोटे ViewControllers के साथ पढ़ने और बनाए रखने के लिए।

यह मदद कर सकता है जो आईओएस में छोटे ViewControllers की तलाश कर रहे हैं:

http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/