2014-12-20 7 views
8

मुझे खेतों में संपत्तियों का उपयोग करने के फायदों के बारे में पता है, जैसे कि भविष्य में आवश्यक होने पर अतिरिक्त तर्क प्रदान करने में सक्षम होना।हम सी # में डेटा बाध्यकारी के लिए सार्वजनिक क्षेत्रों का उपयोग क्यों नहीं कर सकते?

लेकिन मैं वास्तव में क्यों यह डेटा या JavaScriptSerializer वर्ग की तरह JSON serializers के लिए भी बंधन के लिए सार्वजनिक क्षेत्रों उपयोग करने के लिए संभव नहीं है।

क्या इन मामलों में सार्वजनिक क्षेत्रों को अनदेखा करने का कोई अच्छा कारण है? या यह सिर्फ कुछ तरह का सम्मेलन है? या सिर्फ उपयोगकर्ताओं को गुणों का उपयोग करने के लिए मजबूर करने के लिए?

उत्तर

6

लघु संस्करण यह है कि public (या वास्तव में, यहां तक ​​कि protected) के बजाय हमेशा गुणों का उपयोग करते हुए फ़ील्ड बहुत शुरुआत से ही .NET में मौलिक डिज़ाइन पसंद रहा है।

थोड़ा लंबा संस्करण यह है कि public फ़ील्ड के लिए समर्थन जोड़ने से डेटा बाध्यकारी ढांचे में जटिलता बढ़ जाएगी (जो भी आप इसका जिक्र कर रहे हैं)। फ़ील्ड में परिवर्तन अधिसूचना के लिए किसी प्रकार का समर्थन भी नहीं है, जो डेटा बाध्यकारी का एक महत्वपूर्ण पहलू है (कम से कम एक राज्यव्यापी वातावरण जैसे विनफॉर्म विकास)। मूल्यों को पुनर्प्राप्त करने और सेट करने के स्तर पर भी, फ़ील्ड और गुण अलग-अलग हैं; जबकि किसी संपत्ति के मूल्य को पुनर्प्राप्त करने या सेट करने के लिए VB.NET या C# में सिंटैक्स (डिज़ाइन द्वारा) फ़ील्ड के समान होता है, तो प्रोग्राम बाध्यकारी जैसे प्रोग्रामेटिक परिदृश्य में ऐसा करने के लिए उपयोग की जाने वाली तंत्र गुण बनाम भिन्न होती है। खेत।

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

3

इस प्रतिबंध के पीछे कोई तकनीकी कारण नहीं है: यह गुणों की सूची सार्वजनिक फ़ील्ड्स जोड़ने के लिए निश्चित रूप से संभव है, और उन से बाध्यकारी अनुमति देते हैं। वास्तव में, .NET में एपीआई हैं जो अकेले नाम के आधार पर स्वचालित रूप से एक संपत्ति या सार्वजनिक क्षेत्र चुनते हैं। उदाहरण के लिए, LINQ के Expression में PropertyOrField विधि है जो अभिव्यक्ति द्वारा अपने पहले पैरामीटर में लौटाए गए प्रकार के आधार पर एक या दूसरे को चुनती है।

हालांकि, फ़ील्ड छोड़कर सार्वजनिक समस्याएं आपको संभावित समस्याओं की एक श्रृंखला में उजागर करती हैं, कि प्रतिबिंब पर निर्भर प्रणालियों के डिजाइनर अक्सर उनके सिस्टम डिज़ाइन से उनके समर्थन को रोककर सार्वजनिक क्षेत्रों के उपयोग को हतोत्साहित करने का प्रयास करते हैं।

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

+0

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

0

जब से तुम इंटरफेस में फील्ड्स की घोषणा नहीं कर सकते हैं, तो आप सार्वजनिक फील्ड्स उपयोग नहीं करना चाहिए। सभी फ़ील्ड केवल निजी होना चाहिए।

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

+0

हालांकि ये दोनों अच्छे अंक हैं, ये बात करते हैं कि गुणों का उपयोग क्यों करना पसंदीदा डिजाइन विकल्प है, क्यों नहीं डेटा बाध्यकारी परिदृश्यों में फ़ील्ड समर्थन मौजूद नहीं है। –

संबंधित मुद्दे

 संबंधित मुद्दे