MVVM में ViewModel या Model को INotifyPropertyChanged लागू करना चाहिए?

Question

मैंने जिन एमवीवीएम उदाहरणों के माध्यम से काम किया है उनमें से अधिकांश में मॉडल कार्यान्वयन था INotifyPropertyChanged, लेकिन जोश स्मिथ के कमांडसिंक में ViewModel के INotifyPropertyChangedउदाहरण हैं ।

मैं अभी भी संज्ञानात्मक रूप से MVVM अवधारणाओं को एक साथ रख रहा हूं, इसलिए मुझे पता नहीं है कि:

• काम INotifyPropertyChangedकरने के लिए आपको ViewModel में रखना होगाCommandSink
• यह मानदंड का सिर्फ एक उन्मूलन है और यह वास्तव में मायने नहीं रखता है
• आपके पास हमेशा मॉडल लागू होना चाहिए INotifyPropertyChangedऔर यह सिर्फ एक गलती है जिसे एक कोड उदाहरण से किसी एप्लिकेशन के लिए विकसित किए जाने पर ठीक किया जाएगा

आपके द्वारा काम की गई एमवीवीएम परियोजनाओं पर दूसरों के अनुभव क्या रहे हैं?

Comments

यदि आप INPC को लागू करते हैं, तो github.com/Fody/PropertyChanged को आज़माएं - यह आपको टाइप करने के हफ्तों को बचाएगा।

— सीएडी

Answer 1

मैं काफी विपरीत कहूंगा, मैंने हमेशा INotifyPropertyChangedअपने व्यू-मॉमेल पर अपना पक्ष रखा - आप वास्तव में अपने मॉडल को काफी WPF विशिष्ट विशेषता के साथ प्रदूषित नहीं करना चाहते INotifyPropertyChanged, जैसे कि सामान को ViewModel में बैठना चाहिए।

मुझे यकीन है कि अन्य लोग असहमत होंगे, लेकिन मैं जिस तरह से काम कर रहा हूं।

Comments

यदि कोई संपत्ति मॉडल में बदलती है तो आप क्या करते हैं? आपको इसे किसी भी तरह से व्यू-मॉडल पर लाना होगा। ईमानदार सवाल, मैं अभी इस पहेली के साथ काम कर रहा हूँ।

— रोजर लिप्सकॉम्ब

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

— स्टीव मिचम

INotifyProperyChanged WPF विशिष्ट नहीं है, यह System.ComponentModel नाम स्थान में रहता है, मैंने इसे WinForms अनुप्रयोगों में उपयोग किया है, INotifyPropertyChanged भी .Net में रहा है। 2.0 के बाद से, WPF केवल 3.0 से

— benPearce

मैं MODEL और VIEWMODEL दोनों में INotifyPropertyChanged लगाने का प्रशंसक हूं। मैं ऐसा नहीं करने का कारण नहीं सोच सकता। जब आपके परिवर्तन में पृष्ठभूमि में परिवर्तन हुआ है, तो VIEWMODEL को सूचित करने का यह एक सुंदर तरीका है जो VIEWMODEL को प्रभावित करता है, जैसे कि VIEW को सूचित करने के लिए इसका उपयोग किया जाता है और VIEWMODEL में परिवर्तन हुए हैं।

— स्कॉटचेयर

@Steve - एक मॉडल की संपत्ति बदल गई है कि ViewModel को सूचित करने के बारे में, ऐसा लगता है जैसे INotifyPropertyChanged "ठीक एक घटना है कि viewmodel में हुक कर सकते हैं" के रूप में ठीक काम करता है। इसका उपयोग क्यों नहीं करते?

— Skybluecodeflier

Answer 2

मैं इस अवधारणा से बहुत असहमत हूं कि मॉडल को लागू नहीं करना चाहिए INotifyPropertyChanged। यह इंटरफ़ेस UI विशिष्ट नहीं है! यह बस एक बदलाव की सूचना देता है। दरअसल, WPF इसका उपयोग परिवर्तनों की पहचान करने के लिए करता है, लेकिन इसका मतलब यह नहीं है कि यह UI इंटरफ़ेस है। मैं इसकी तुलना निम्न टिप्पणी से करूंगा: " एक टायर एक कार सहायक है "। ज़रूर है, लेकिन बाइक, बस आदि भी इसका उपयोग करते हैं। सारांश में, उस इंटरफ़ेस को UI चीज़ के रूप में न लें।

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

हालांकि, चीजों को हासिल करने के अलग-अलग तरीके हैं, लेकिन मैं हमेशा सादगी के पक्ष में बहस करूंगा और अतिरेक से बचूंगा।

क्या बेहतर है? दृश्य मॉडल पर एक संग्रह या संपत्ति में परिवर्तन को परिभाषित करना और इसे मॉडल में प्रचारित करना या दृश्य को आंतरिक रूप से अपडेट करना (दृश्य मॉडल के माध्यम से)?

नीचे की रेखा जब भी आप किसी को यह दावा करते हुए देखते हैं कि " आप ऐसा नहीं कर सकते या यह " यह एक संकेत है कि वे नहीं जानते कि वे किस बारे में बात कर रहे हैं।

यह वास्तव में आपके मामले पर निर्भर करता है और वास्तव में MVVM बहुत सारे मुद्दों के साथ एक रूपरेखा है और मुझे अभी तक बोर्ड भर में MVVM का एक सामान्य कार्यान्वयन देखना बाकी है।

काश मेरे पास एमवीवीएम के कई फ्लेवर और सामान्य समस्याओं के कुछ समाधानों को समझाने के लिए अधिक समय होता - ज्यादातर अन्य डेवलपर्स द्वारा प्रदान किए जाते हैं, लेकिन मुझे लगता है कि मुझे इसे और समय देना होगा।

Comments

इस पर इस तरीके से विचार करें। यदि आप एक डेवलपर के रूप में उपभोग करते हैं, तो आप में मॉडल के साथ एक .dll का उपयोग करें, निश्चित रूप से INotifyPropertyhanhanged का समर्थन करने के लिए उन्हें फिर से लिखना नहीं होगा।

— ली ट्रेविले

दृढ़ता से आपके साथ सहमत हूँ। मेरी तरह, आप भी यह जानकर प्रसन्न हो सकते हैं कि आधिकारिक MVVM प्रलेखन < msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx > (मॉडल अनुभाग हमारे साथ सहमत है)। :-)

— नोल्डोरिन

"हालांकि, तहर चीजों को हासिल करने के अलग-अलग तरीके हैं लेकिन मैं हमेशा सादगी के पक्ष में बहस करूंगा और अतिरेक से बचूंगा।" बहोत महत्वपूर्ण।

— बस्तियन वंदामे

INotifyPropertyChangedSystem.ComponentModelनामस्थान का एक हिस्सा है जो " रन-टाइम और घटकों और नियंत्रणों के डिज़ाइन-टाइम व्यवहार " के लिए है। मॉडल में उपयोग न करें INotifyPropertyChanged , सिर्फ ViewModels में। डॉक्स के लिए लिंक: docs.microsoft.com/en-us/dotnet/api/system.componentmodel

— इगोर पोपोव

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

— रिहायस

Answer 3

MV-VM में ViewModel हमेशा (मॉडल हमेशा नहीं) लागू होता है INotifyPropertyChanged

Http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx से MV-VM प्रोजेक्ट टेम्प्लेट / टूलकिट देखें । यह DelegateCommandकमांडिंग के लिए उपयोग करता है और यह आपके लिए एमवी-वीएम परियोजनाओं के लिए एक शानदार शुरुआती टेम्प्लेट होना चाहिए।

Comments

यह पहला वाक्य दूसरे जवाबों के विकल्प को बहुत अच्छी तरह से बताता है, इमो। => UPVOTE!

— j00hi

Answer 4

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

यदि आप View-Model को DataController के रूप में मानते हैं और एक आर्किटेक्चर को लागू करते हैं जहां आपका DataController एकमात्र आइटम है जो डेटा को छूता है, तो आप कभी भी डेटा को सीधे नहीं छूएंगे, लेकिन हमेशा डेटा कंट्रोलर का उपयोग करें। DataController यूआई के लिए उपयोगी है, लेकिन केवल यूआई के लिए आवश्यक नहीं है। यह व्यापार परत, UI परत, आदि के लिए है ...

DataModel -------- DataController ------ View
                  /
Business --------/

आप इस तरह से एक मॉडल के साथ समाप्त होते हैं। यहां तक ​​कि व्यवसाय को केवल ViewModel का उपयोग करके डेटा को स्पर्श करना चाहिए। फिर आपका कॉनड्रम बस चला जाता है।

Comments

यह बहुत अच्छा है यदि आपका डेटा केवल तभी बदलता है जब DataController इसे बदलता है। यदि डेटा किसी डेटाबेस या कुछ अन्य डेटास्टोर से आता है जो परिवर्तन के लिए दूसरा एवेन्यू प्रदान कर सकता है, तो आपको VIEWMODEL (अपने पैटर्न में डेटा कंट्रोलर) को सूचित करने और ऐसा होने पर देखने का एक तरीका होना चाहिए। आप या तो DataController का उपयोग करके चुनाव कर सकते हैं या अपने DataModel में कुछ बाहरी प्रक्रिया से धक्का दे सकते हैं और अपने DataModel को अपने DataController को परिवर्तन सूचनाएं भेज सकते हैं।

— 21

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

— रिह्यूस

आप अपने डेटा कंट्रोलर को भी धक्का देंगे क्योंकि यह डेटा मॉडल को नियंत्रित करता है और इसे अपडेट करने के लिए कहेगा।

— रिहायस

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

— कोड का नाम जैक

Answer 5

यह इस बात पर निर्भर करता है कि आपने अपना मॉडल कैसे लागू किया है। मेरी कंपनी लोटका की CSLA वस्तुओं के समान व्यावसायिक वस्तुओं का उपयोग करती है और INotifyPropertyChangedपूरे व्यापार मॉडल का व्यापक उपयोग करती है ।

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

हमारे पास व्यू मॉडल भी हैं जो मॉडल से उन परिवर्तनों को प्रचारित करते हैं जहां जरूरत होती है, लेकिन देखें मॉडल स्वयं अंतर्निहित मॉडल परिवर्तनों को सुन रहे हैं।

Comments

आप वास्तव में मॉडल के OnPropertyChanged को ViewModel के OnPropertyChanged में कैसे प्रचारित करते हैं? मुझे एक समस्या है जब ViewModel में मॉडल की तुलना में अलग-अलग संपत्ति के नाम हैं - किसी प्रकार का नाम-टू-नाम मैपिंग की आवश्यकता होगी, तब?

— मार्टिन कोनिसक

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

— स्टीव मिचम

Answer 6

मैं पाउलो के जवाब से सहमत हूं, INotifyPropertyChangedमॉडल में लागू करना पूरी तरह से स्वीकार्य है और यहां तक ​​कि माइक्रोसॉफ्ट द्वारा भी सुझाया गया है -

आमतौर पर, मॉडल उन सुविधाओं को लागू करता है जो दृश्य को बांधने में आसान बनाते हैं। इसका आमतौर पर मतलब है कि यह संपत्ति और संग्रह के माध्यम से INotifyPropertyChangedऔर अधिसूचना के माध्यम से बदल अधिसूचना का समर्थन करता INotifyCollectionChangedहै। मॉडल वर्ग जो वस्तुओं के संग्रह का प्रतिनिधित्व करते हैं, आमतौर पर ObservableCollection<T>वर्ग से प्राप्त होते हैं , जो INotifyCollectionChangedइंटरफ़ेस का कार्यान्वयन प्रदान करता है।

हालाँकि इसका निर्णय आप पर है कि आप उस प्रकार का कार्यान्वयन चाहते हैं या नहीं, लेकिन याद रखें -

क्या होगा यदि आपके मॉडल वर्ग आवश्यक इंटरफेस को लागू नहीं करते हैं?

कभी-कभी आप मॉडल ऑब्जेक्ट को लागू नहीं करते के साथ काम करने की आवश्यकता होगी INotifyPropertyChanged, INotifyCollectionChanged, IDataErrorInfo, या INotifyDataErrorInfoइंटरफेस। उन मामलों में, दृश्य मॉडल को मॉडल ऑब्जेक्ट्स को लपेटने और देखने के लिए आवश्यक गुणों को उजागर करने की आवश्यकता हो सकती है। इन गुणों के लिए मान सीधे मॉडल ऑब्जेक्ट द्वारा प्रदान किए जाएंगे। व्यू मॉडल उन संपत्तियों के लिए आवश्यक इंटरफेस को लागू करेगा जो इसे उजागर करता है ताकि दृश्य आसानी से डेटा बाइंड कर सके।

से लिया गया - http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

मैंने कुछ परियोजनाओं में काम किया है जहाँ हमने INotifyPropertyChangedअपने मॉडलों में लागू नहीं किया है और इस वजह से हमें बहुत सारे मुद्दों का सामना करना पड़ा है; वीएम में संपत्तियों के अनावश्यक दोहराव की आवश्यकता थी और साथ ही हमें बीएल / डीएल को पास करने से पहले अंतर्निहित वस्तु (अद्यतन मूल्यों के साथ) को अपडेट करना था।

यदि आपको अपने मॉडल ऑब्जेक्ट्स (एक संपादन योग्य ग्रिड या सूची में कहें) या जटिल मॉडल के संग्रह के साथ काम करने की आवश्यकता है तो आपको विशेष रूप से समस्याओं का सामना करना पड़ेगा; मॉडल ऑब्जेक्ट स्वचालित रूप से अपडेट नहीं किए जाएंगे और आपको अपने वीएम में सभी को प्रबंधित करना होगा।

Answer 7

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

Answer 8

मुझे लगता है कि यदि आप एमवी-वीएम का पालन करना चाहते हैं तो इसका उत्तर काफी स्पष्ट है।

देखें: http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

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

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

Comments

उद्धरण व्याख्या के लिए खुला है। मुझे लगता है कि आपको अपना जवाब जोड़ना चाहिए, अपना उत्तर स्पष्ट करने के लिए :-)

— सोरेन बोइसन

@ जॉन डी: यह लेख सिर्फ एमवीवीएम की एक व्याख्या और इसे लागू करने का एक तरीका देता है, यह एमवीवीएम को परिभाषित नहीं करता है।

— अजोशी

इसके अलावा, यदि आप पूरा लेख पढ़ते हैं तो यह मॉडल वर्ग को इस तरह परिभाषित करता है: "आमतौर पर, मॉडल उन सुविधाओं को लागू करता है जो इसे देखने में आसानी से बांधती हैं। इसका आमतौर पर मतलब यह है कि यह संपत्ति और संग्रह को INotifyPropertChanged और INotifyCollectionChanged interfaces के माध्यम से परिवर्तित अधिसूचना का समर्थन करता है। । मॉडल वर्ग जो वस्तुओं के संग्रह का प्रतिनिधित्व करते हैं, वे आमतौर पर ऑब्जर्वेबल कॉलेक्शन <टी> क्लास से निकलते हैं, जो कि इनोटिफ़ाइक्लेक्शनियन चेंजेड इंटरफ़ेस का कार्यान्वयन प्रदान करता है। "

— अजोशी

Answer 9

मैं आपके ViewModel में कहूंगा। यह मॉडल का हिस्सा नहीं है क्योंकि मॉडल UI अज्ञेयवादी है। आदर्श होना चाहिए 'सब कुछ EXCEPT व्यापार अज्ञेय'

Answer 10

यदि मॉडल में ViewModel में स्पष्ट रूप से उजागर किया जाता है, तो मॉडल में INPC को लागू किया जा सकता है। लेकिन आम तौर पर, मॉडल जटिलता को कम करने के लिए ViewModel मॉडल अपनी स्वयं की कक्षाएं हैं (जो बाध्यकारी के लिए उपयोगी नहीं होनी चाहिए)। इस मामले में INPC को ViewModel में लागू किया जाना चाहिए।

Answer 11

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

मैंने कई फायदे और नुकसान देखे हैं:

लाभ

नोटिफिकेशन बिजनेस मॉडल में है

1. डोमेन के अनुसार, यह सही है। यह तय करना चाहिए कि कब उठाना है और कब नहीं।

नुकसान

मॉडल में गुण (मात्रा, दर, कमीशन, कुल मिलाकर) हैं। Totalfrieght की गणना मात्रा, दर, कमीशन परिवर्तन का उपयोग करके की जाती है।

1. Db से मानों को लोड करने पर, कुल फ्रिक्ट गणना को 3 गुना (मात्रा, दर, कमीशन) कहा जाता है। यह एक बार होना चाहिए।

2. यदि दर, मात्रा व्यापार परत में दी गई है, तो फिर से नोटिफ़ायर कहा जाता है।

3. इसे अक्षम करने का विकल्प होना चाहिए, संभवतः आधार वर्ग में। हालांकि, डेवलपर्स ऐसा करना भूल गए।

Comments

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

— try2fly.b4ucry

Answer 12

मुझे लगता है कि यह सब उपयोग के मामले पर निर्भर करता है।

जब आपके पास गुणों के भार के साथ एक सरल मॉडल होता है, तो आप इसे INPC को लागू कर सकते हैं। साधारण से मेरा मतलब है कि यह मॉडल एक POCO की तरह दिखता है ।

यदि आपका मॉडल अधिक जटिल है और एक इंटरेक्टिव मॉडल डोमेन में रहता है - मॉडल संदर्भित मॉडल, अन्य मॉडल की घटनाओं की सदस्यता - आईएनपीसी के रूप में कार्यान्वित मॉडल इवेंट एक बुरा सपना है।

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

INPC के साथ एक और मुद्दा। आपको अपने ऐप्स को अमूर्तता पर भरोसा करने के लिए डिज़ाइन करना चाहिए, कार्यान्वयन नहीं। यह आमतौर पर इंटरफेस का उपयोग करके किया जाता है।

आइए एक ही अमूर्त के 2 अलग-अलग कार्यान्वयनों पर एक नज़र डालें:

public class ConnectionStateChangedEventArgs : EventArgs
{
    public bool IsConnected {get;set;}
}

interface IConnectionManagerINPC : INotifyPropertyChanged
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    bool IsConnected {get;}
}

interface IConnectionManager
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    event EventHandler<ConnectionStateChangedEventArgs> ConnectionStateChanged;
    bool IsConnected {get;}
}

अब दोनों को ही देख लीजिए। IConnectionManagerINPC आपको क्या बताता है? कि इसके कुछ गुण बदल सकते हैं। आप उनमें से कौन नहीं जानते। वास्तव में डिजाइन यह है कि केवल कटा हुआ परिवर्तन होता है, क्योंकि उनमें से बाकी केवल-पढ़ने के लिए होते हैं।

इसके विपरीत, IConnectionManager के इरादे स्पष्ट हैं: "मैं आपको बता सकता हूं कि मेरी IsConnected संपत्ति का मूल्य बदल सकता है"।

Answer 13

बस INotifyPropertyChangeअपने दृष्टिकोण में उपयोग करें और मॉडल में नहीं,

मॉडल आमतौर पर IDataErrorInfoसत्यापन त्रुटियों को संभालने के लिए उपयोग करता है इसलिए बस अपने ViewModel में रखें और आप अपने MVVM सड़क पर सही हैं।

Comments

कई गुणों वाले मॉडल के बारे में क्या? आप वीएम में कोड दोहरा रहे हैं।

— लुइस

Answer 14

मान लीजिए कि आपके विचार में ऑब्जेक्ट का संदर्भ बदल जाता है। सही मान दिखाने के लिए आप सभी संपत्तियों को कैसे अपडेट किया जाएगा? OnPropertyChangedसभी ऑब्जेक्ट के गुणों के लिए आपके विचार में कॉल करना मेरे दृष्टिकोण के लिए बकवास है।

इसलिए मैं जो कुछ करता हूं, वह यह है कि किसी संपत्ति के मूल्य में बदलाव होने पर किसी को भी सूचित करने के लिए वस्तु को खुद को सूचित करने के लिए, और मेरे विचार में मैं बाइंडिंग का उपयोग करता हूं Object.Property1, Object.Property2और। इस तरह से अगर मैं सिर्फ उस वस्तु को बदलना चाहता हूं जो वर्तमान में मेरे विचार में बनी हुई है तो मैं बस कर देता हूं OnPropertyChanged("Object")।

वस्तुओं को लोड करने के दौरान सैकड़ों सूचनाओं से बचने के लिए, मेरे पास एक निजी बूलियन संकेतक है जिसे मैंने लोड करने के दौरान सही पर सेट किया है जो ऑब्जेक्ट से चेक किया गया है OnPropertyChangedऔर कुछ भी नहीं करता है।

Answer 15

आम तौर पर ViewModel को लागू करेगा INotifyPropertyChanged। मॉडल कुछ भी हो सकता है (xml फ़ाइल, डेटाबेस या ऑब्जेक्ट)। मॉडल का उपयोग व्यूमोडेल को डेटा देने के लिए किया जाता है, जो दृश्य को प्रसारित करता है।

यहाँ देखें

Comments

ईएमएम .. नहीं। मॉडल xml फ़ाइल या डेटाबेस नहीं हो सकता। और डेटा देने के लिए मॉडल का उपयोग नहीं किया जाता है। अन्यथा इसे "मॉडल" नहीं बल्कि "डेटा" कहा जाना चाहिए ..? मॉडल का उपयोग डेटा का वर्णन करने के लिए किया जाता है। काफी आत्म व्याख्यात्मक, है ना? :)

— तरास

यदि आपके पास एक बेहतर उत्तर है, तो pls साझा करें! हम सभी यहाँ ज्ञान साझा करने और प्रतिस्पर्धा करने के लिए नहीं हैं

— एडम

Answer 16

imho मुझे लगता है कि दृश्यमॉडल लागू होता है INotifyPropertyChangeऔर मॉडल एक अलग "स्तर" पर अधिसूचना का उपयोग कर सकता है।

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

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

Answer 17

सभी गुण, जो मेरे विचार से जुड़े हैं, मेरे ViewModel (s) में हैं। इस प्रकार उन्हें INotifyPropertyChanged इंटरफ़ेस लागू करना चाहिए। इसलिए व्यू को सभी परिवर्तन मिलते हैं।

[MVVM लाइट टूलकिट का उपयोग करके, मैंने उन्हें ViewModelBase से विरासत में मिला।]

मॉडल व्यावसायिक तर्क रखता है, लेकिन दृश्य के साथ इसका कोई लेना-देना नहीं है। इस प्रकार INotifyPropertyChanged इंटरफ़ेस की कोई आवश्यकता नहीं है।