INotifyProperty डेटा बाध्यकारी के बाहर का उपयोग किया गया

Question

मैंने कभी भी INotifyPropertyChanged का उपयोग नहीं किया है, और मैं इसे एक नए एप्लिकेशन में व्यापक रूप से उपयोग करने पर विचार कर रहा हूं।

मेरा सवाल है, क्या यह डाटाबेस नियंत्रण के अलावा अन्य चीज़ों के लिए ईवेंट नोटिफिकेशन प्रदान करने के लिए INOTifyPropertyChanged इंटरफ़ेस का उपयोग करना उचित है?

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

Answer 1

इस तरह की पसंद करते समय, मैं अन्य संरचनाओं पर भाषा सुविधाओं का उपयोग करने की ओर झुकता हूं।

INotifyPropertyChanged के लिए एक गंभीर नकारात्मक पक्ष यह है कि यह केवल संपत्ति नाम को अद्यतन पर एक स्ट्रिंग के रूप में प्रदान करता है, और आपके उपभोग करने वाले वर्गों को उस स्ट्रिंग को पार्स करना होगा और यह तय करना होगा कि इस पर कार्य कैसे करें।

घटनाओं के साथ आप किसी भी तरह के प्रतिनिधि हस्ताक्षर प्रदान कर सकते हैं कि घटना की आवश्यकता है और उपभोग करने वाले वर्ग सीधे उस परिवर्तन पर कार्य कर सकते हैं।

यदि आप हुड के नीचे देखते हैं, तो आप पाएंगे कि INotifyPropertyChanged एक घटना है, तो घटनाओं का सीधे उपयोग क्यों न करें?

Answer 2

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

Answer 3

मुझे लगता है कि आपको INotifyPropertyChanged इंटरफ़ेस को लागू करने के लिए आगे बढ़ना चाहिए, क्योंकि यह उस उद्देश्य के लिए है और यूआई जो बदलावों को बदलने के लिए उपयोग करता है, वहां कस्टम ईवेंट बनाने की आवश्यकता नहीं है।

Answer 4

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

अन्यथा, जहां तक ​​मुझे पता है, यह .NET Framework प्रौद्योगिकियों को प्रभावित नहीं करता है।

INotifyPropertyChanged आपकी संपत्ति में बदलाव के दौरान सूचित करने का सबसे साफ तरीका नहीं है, इस पर निर्भर करता है कि आप इसे कैसे देखते हैं, क्योंकि एक ईवेंट और संपत्ति नाम के साथ एक स्ट्रिंग है, आपको स्विच स्टेटमेंट करना होगा। यह सुनिश्चित करना आसान है कि संपत्ति प्रति घटनाओं की तुलना में कार्यान्वित करना आसान है हालांकि

Answer 5

मैं डाटाबेसिंग को छोड़कर कुछ भी के लिए INotifyPropertyChanged का उपयोग नहीं करता। यह इंटरफ़ेस शायद डाटाबेसिंग का एकमात्र विकल्प है क्योंकि नियंत्रण PropertyChanged ईवेंट पर कार्य करेगा, प्रेषक के प्रकार को पहले से नहीं जानता है। उस डेटाबेस के कारण इस तरह के एक सामान्य इंटरफेस का उपयोग करना है।

अपने स्वयं के प्रकार और परिदृश्यों के लिए मैं नियमित घटनाओं का उपयोग करता हूं (प्रत्येक संपत्ति के लिए एक घटना जो इसके मूल्य को बदल सकती है)। इस तरह के परिदृश्यों में INotifyPropertyChanged कड़े टाइप किए गए कोड की तरह है। आप देख सकते हैं कि यहां तक ​​कि WPF स्वयं भी पुरानी स्कॉल घटनाओं से भरा हुआ है (FrameworkElement उदाहरण के लिए ***Changed ईवेंट के साथ)।

Answer 6

मुझे लगता है कि INotifyPropertyChanged आमतौर पर संपत्ति मूल्य अपडेट के बारे में पुश-आधारित सूचनाओं के लिए सही तंत्र है।

वैकल्पिक:

हालांकि, यह है कि अंत में ही संभव तंत्र नहीं मानता। उदाहरण के लिए, विंडोज फॉर्म प्रति संपत्ति अलग …Changed घटनाओं का भी समर्थन करता है; यानी यदि आपके पास Foo नाम की एक संपत्ति है, तो आप FooChanged ईवेंट से जुड़े हो सकते हैं जो Foo के सेटर में ट्रिगर किया जाएगा।

अलग …Changed घटनाओं के बाद की आवश्यकता नहीं है पर्यवेक्षकों/ग्राहकों गुण है कि वे में दिलचस्पी नहीं है के लिए सूचनाएं बाहर फिल्टर करने के लिए एक विशेष संपत्ति के लिए विशिष्ट होने का लाभ दिया है, और इस तरह। दूसरी ओर, अपने (डेटा) 50 अतिरिक्त …Changed घटनाओं को घोषित करने के बाद वस्तुओं को "भारी" महसूस करना शुरू हो सकता है।

INotifyPropertyChanged लागू करने के बारे कुछ नोट:

• आप से थक तो फिर से लिख ही बॉयलरप्लेट कोड फिर से और फिर ...:

  public T SomeProperty 
  { 
      get { … } 
      set 
      { 
       if (someProperty != value) 
       { 
        someProperty = value; 
        NotifyPropertyChanged("SomeProperty"); 
       } 
      } 
  } 
  private T someProperty; 
  

  तो आप करने के लिए चाहते हो सकता है एक एओपी ढांचे पर विचार करें (जैसे PostSharp)। मुझे याद है कि कोडप्लेक्स या Google कोड पर लाइब्रेरी है जो आपके लिए INotifyPropertyChanged स्वत: लागू करता है (या सीआईएल बाइटकोड पुनः लिख रहा है); दुर्भाग्य से मैं पुस्तकालय के नाम को याद नहीं कर सकता।

• अन्य संबंधित इंटरफेस INotifyPropertyChanging, INotifyListChanged आदि हैं। आप इन्हें भी देखना चाहेंगे।

Answer 7

न उपयोग करते हैं, अन्य स्थितियों में है अगर आप, अधिक व्यापार उन्मुख जो किया जाएगा और वर्णनात्मक और दृढ़ता से

Answer 8

टाइप किया अन्य डोमेन कक्षाओं के बजाय डोमेन घटनाओं का उपयोग सूचित करने की आवश्यकता मैं INPC के एक प्रशंसक के बाहर नहीं कर रहा हूँ यूआई क्षेत्रों के रूप में यह इस तथ्य को छुपाता है कि वस्तु के उदाहरणों से महत्वपूर्ण घटनाएं उत्पन्न की जा रही हैं। इसके अलावा, अगर मैं आपके कक्षा को लागू करने के लिए आईएनपीसी का उपयोग करता हूं, तो मैं सभी गुणों को प्रसारित करने के लिए गुणों की अपेक्षा करूंगा, अगर उनमें से केवल कुछ ही रनटाइम पर एक बग है जो अनजान हो सकता है।