क्या हमें किसी मॉडल प्रॉपर्टी को देखने के लिए बाध्य होना चाहिए या ViewModel का अपना होना चाहिए ..?

Question

मैं निम्नलिखित तकनीकी वातावरण के साथ एक परियोजना शुरू कर रहा हूं: .नेट 4.0, एंटिटी फ्रेमवर्क 4.0, एमवीवीएम आर्किटेक्चर के साथ डब्ल्यूपीएफ

मैंने नेट पर बहुत सारे उदाहरण देखे, कुछ किताबें इस माहौल के साथ। कुछ उदाहरणों में लेखकों के पास यह विचार था:

1. वीमॉडल में मॉडल क्लास (एंटिटी फ्रेमवर्क एंटिटी उदा पर्सन) का एक उदाहरण होगा
2. WPF दृश्य नियंत्रण को मॉडल के गुणों से बांधें

जबकि कुछ लेखकों ने किया:

1. वेमोडेल मॉडल के सभी गुणों को उजागर करेगा।
2. सीधे मॉडल के बजाय ViewModel के गुणों पर WPF दृश्य नियंत्रणों को बांधें।

तो क्या यह एक अच्छा विचार है कि दृश्य को मॉडल से बाइंड करने के गुणों को देखने के बजाय व्यूमॉडल को स्वयं को उजागर करने दें? या कौन सा ज्यादा पसंद किया जाता है?

Comments

व्यक्तिगत रूप से मुझे आपके डेटा लेयर और लॉजिक लेयर्स के अच्छे विभाजन के परिणामस्वरूप मॉडल के गुणों को उजागर करना है।

— एलेक्स होप ओ'कॉनर

Answer 1

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

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

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

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

Comments

मुझे आपका जवाब पसंद है। +1 संपादित / सहेजें स्क्रीन का उल्लेख करने के लिए .. लेकिन फिर दो बार गुणों को लिखना कठिन होगा - एक बार मॉडल में और फिर से दृश्य-मॉडल में। इससे विकास का समय भी बढ़ेगा। क्या आपको लगता है कि ऐसा करना उचित है ...?

— प्रवीण पाटिल

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

— स्कॉट व्हिटलॉक 15

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

— फाल्कन

Answer 2

एक ViewModelकी बात यह है कि यह एक मॉडल है View।

आपको किसी भी गुण नहीं (सीधे नहीं, वैसे भी) के ViewModelलिए बाध्य होना चाहिए ।ViewModel

Answer 3

मुझे दोनों ही तरीके स्वीकार्य हैं

केवल ViewModel को बांधना "MVVM-purist" दृष्टिकोण है और परतों के बीच बेहतर अलगाव की ओर जाता है। मॉडल से बांधना आमतौर पर तेज़ और अधिक सुविधाजनक होता है।

जब तक मेरे पास परतों को पूरी तरह से अलग करने का एक अच्छा कारण नहीं है (परियोजना का आकार, भविष्य के रखरखाव की चिंताएं, मैं किस प्रकार के मॉडल के साथ काम कर रहा हूं, आदि), मैं मॉडल से बांधता हूं।

Answer 4

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

छद्म कोड:

 {Binding: MyViewModel.MyModel.Name}

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

यदि आप केवल दृश्य-मॉडल के रूप में दूर तक बाँधते हैं, तो आप मॉडल को बदल सकते हैं और दृश्य कभी भी नहीं जान पाएंगे क्योंकि यह केवल दृश्य-मॉडल पर नाम नाम की संपत्ति को देखेगा।

अब इसे कुछ परिस्थितियों में कम किया जा सकता है क्योंकि आपका मॉडल एक इंटरफ़ेस से बाहर है। इसलिए यदि इंटरफ़ेस में एक IBaseDetails था जिसने संपत्ति ModuleName को उजागर किया था तो आप निम्न कर सकते थे:

छद्म कोड:

 {Binding: MyViewModel.MyModel.ModuleName}

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

Answer 5

यदि आप मॉडल -> ViewModel से जाने के लिए बहुत अधिक घर्षण देख रहे हैं, तो AutoMapper की तरह कुछ आज़माएं। यह मैन्युअल रूप से कॉपी करने वाले गुणों से जुड़े टेडियम को हटा देता है।

Answer 6

मैं यहां सिर्फ इसलिए गया क्योंकि मुझे भी यही संदेह था और मुझे विश्वास हो गया कि मैं हमेशा मॉडल के बजाय मॉडल को देखने के लिए बाध्य रहूंगा।

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

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

एक ही मॉडल को बचाने / रद्द करने के मामले में अद्यतन करने के लिए हो सकता है और अधिक साफ नहीं है।

Comments

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। आप आपत्ति तो नहीं है संपादित एक बेहतर आकार में यह ing?

— gnat

वहाँ तुम जाओ, चीयर्स।

— इवान कार्मेनेट्स गार्सिया