2013-10-31 8 views
6

में जनता के बजाय बाध्यकारी संपत्ति आंतरिक बनाना I MVVM का उपयोग करके कुछ अलग-अलग चीजों को आजमा रहा हूं। हमारे व्यू मॉडेल गुणों में जो देखने के लिए बाध्य हैं सार्वजनिक हैं। मैं एक बटन बाध्यकारी का उदाहरण ले रहा हूँ। यहां एक साधारण नमूना है।व्यूमोडेल

View.xaml:

<Button Content="Test Button" Command="{Binding TestButtonCommand}" /> 

ViewModel.cs

private ICommand _testButtonCommand; 
public ICommand TestButtonCommand 
{ 
    get { return _testButtonCommand?? (_testButtonCommand= new RelayCommand(SomeMethod)); } 
} 

यहाँ मेरे सवाल है कि हम TestButtonCommand आंतरिक बजाय जनता के कर सकते हैं? आंतरिक साधन यह वर्तमान परियोजना के लिए सुलभ है, इसलिए उन्हें ऐसा करने में कोई समस्या नहीं होनी चाहिए? लेकिन जब मैंने ऐसा करने की कोशिश की तो यह काम नहीं किया। गेटटर में ब्रेकपॉइंट जोड़ना हिट नहीं हुआ था। तो हम इसे आंतरिक क्यों नहीं बना सकते हैं।

यहां एमएसडीएन का लिंक है।

http://msdn.microsoft.com/en-us/library/ms743643.aspx

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

हम ऐसा क्यों नहीं कर सकते? एक ही प्रोजेक्ट में काम करते समय आंतरिक पहुंच के मामले में सार्वजनिक के समान ही है। तो हम यहां आंतरिक का उपयोग क्यों नहीं कर सकते हैं। एक कारण होना चाहिए कि ये सार्वजनिक होना चाहिए, और मैं उस कारण की तलाश में हूं।

internal ICommand TestButtonCommand { ...... } 
+3

क्योंकि [आप केवल सार्वजनिक गुण, उप-गुण और अनुक्रमणिका या किसी भी सीएलआर ऑब्जेक्ट से जुड़ सकते हैं] (http://msdn.microsoft.com/en-us/library/ms743643.aspx)। डब्ल्यूपीएफ टीम इस तरह के डिजाइन निर्णय के साथ क्यों गई? मुझे नहीं पता, आपको उनसे पूछना चाहिए :) –

+0

इसका माइक्रोसॉफ्ट, इसलिए हम कुछ भी नहीं कर सकते हैं, –

उत्तर

11

उसी आंतरिक प्रोजेक्ट में काम करने पर आंतरिक आंतरिक पहुंच के मामले में सार्वजनिक के समान होता है। तो हम यहां आंतरिक का उपयोग क्यों नहीं कर सकते हैं। का कारण होना चाहिए कि ये सार्वजनिक होना चाहिए, और मैं उस कारण की तलाश में हूं।

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

+2

फिर, मॉडल वर्ग को देखने के लिए बाध्य करना संभव है जो स्वयं आंतरिक है? –

+1

मैन, ओह, मैन यह मुझे Winforms में पागल कर रहा था। स्पष्ट और अभी तक एक ही समय में सभी नहीं। धन्यवाद। –

7

Binding केवल सार्वजनिक गुणों के लिए समर्थित है। MSDN संदर्भ:

http://msdn.microsoft.com/en-us/library/ms743643.aspx

संदर्भ में उद्धृत

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

+0

मैं यहां खोजने की कोशिश कर रहा हूं कि हम आंतरिक उपयोग नहीं कर सकते हैं। अगर हम एक ही परियोजना में काम कर रहे हैं तो यह जनता जैसा ही है। –

0

निर्मित आंतरिक संपत्ति अच्छी ओओ डिजाइन तोड़ रही है और encapsulation तोड़ रहे हैं। आप अपने मामले के लिए आंतरिक सेट एक्सेसर (और सार्वजनिक एक्सेस प्राप्तकर्ता) का उपयोग कर सकते हैं।

public ICommand SaveCommand 
{ 
    get; 
    internal set; 
} 

आप एक क्षेत्र में एक संपत्ति में समझाया है, तो आप यह हमेशा यहां तक ​​कि अपने वर्ग के भीतर एक संपत्ति सोचा कि क्षेत्र तक पहुँचने के लिए एक नियम बनाना चाहिए। यह सबसे अच्छा अभ्यास है।

1

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

के बाद से वहाँ पहुँच नियमों को लागू करने के लिए कोई रास्ता नहीं है, की अनुमति के internal गुण के लिए बाध्य private गुण, नहीं public गुणों के बंधन की इजाजत दी के बराबर होगा।

0

http://msdn.microsoft.com/en-us/library/ms743643.aspx

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

2

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

उन्हें पुस्तकालय के 'उपयोगकर्ता से छिपाने के लिए मेरे समाधान प्रत्येक संपत्ति है कि मेरे पास बहुत कम या कोई ब्याज भालू को

<EditorBrowsable(EditorBrowsableState.Never)> 

विशेषता जोड़ने के लिए है।

आशा है कि किसी की मदद करें!

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