मैं सोच रहा हूँ अगर यह एक अच्छा विचार है सत्यापनमें ही टिककर खेल और setters, या कहीं और कोड में बनाने के लिए।गेटर/सेटर या अन्य जगहों में डेटा सत्यापन?
यह आश्चर्यजनक हो सकता है आप जब यह अनुकूलन और कोड को तेज करने, मुझे लगता है कि आप getters और setters में सत्यापन नहीं करना चाहिए, लेकिन करने के लिए आता हो कोड जहां रहे आपकी फ़ाइलों को अद्यतन करने में या डेटाबेस। क्या मै गलत हु?
ठीक है, रेनॉन्स में से एक क्यों कक्षाओं में आम तौर पर सार्वजनिक गेटर्स/सेटर्स के साथ निजी सदस्य होते हैं क्योंकि वे डेटा सत्यापित कर सकते हैं।
आप एक संख्या से कम 1 और 100 के बीच हो सकता है है, तो मैं निश्चित रूप से कुछ सेटर कि कि पुष्टि करता है और तो शायद एक अपवाद है कि कोड द्वारा पकड़े जाने फेंक जाते थे। वजह साफ है: आप सेटर में ऐसा नहीं है, तो आप को याद करने के लिए है कि 1 हर बार जब आप यह निर्धारित करते हैं, जो डुप्लिकेट किए गए कोड की ओर जाता है या जब आप इसे भूल जाते हैं, यह एक अमान्य स्थिति की ओर जाता है 100 करने के लिए सीमा।
प्रदर्शन के लिए के रूप में, मैं यहाँ नुथ साथ हूँ:
"हम छोटे क्षमता के बारे में भूल जाना चाहिए, का कहना है कि समय की 97%:। समय से पहले अनुकूलन सब बुराई की जड़ है"
प्रमाणीकरण विधि में गेटर्स या सेटर्स से प्रमाणीकरण अलग से कब्जा किया जाना चाहिए। इस तरह यदि सत्यापन को कई घटकों में पुन: उपयोग करने की आवश्यकता है, तो यह उपलब्ध है।
जब सेटटर कहा जाता है, तो इस तरह की सत्यापन सेवा का उपयोग वस्तु में इनपुट को स्वच्छ करने के लिए किया जाना चाहिए। इस तरह आप जानते हैं कि किसी ऑब्जेक्ट में संग्रहीत सभी जानकारी हमेशा वैध होती है।
आपको गेटर के लिए किसी भी तरह की सत्यापन की आवश्यकता नहीं है, क्योंकि ऑब्जेक्ट पर जानकारी पहले से ही मान्य होने पर भरोसा है।
डेटाबेस अपडेट तक अपना सत्यापन सहेज न करें !! यह बेहतर है तेजी से विफल।
सबसे अधिक रखरखाव कोड रखने के परिप्रेक्ष्य से, मुझे लगता है कि आपको संपत्ति के सेटटर में जितना अधिक सत्यापन करना चाहिए। इस तरह आप अमान्य डेटा से कैशिंग या अन्यथा व्यवहार नहीं करेंगे।
आखिरकार, यह संपत्तियों के लिए क्या है। यदि आप केवल इतना है की तरह गुण का एक समूह ...
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
है ... वे के साथ-साथ खेतों
यह निर्भर करता है हो सकता है।
आम तौर पर, कोड तेजी से विफल होना चाहिए। यदि मान कोड में एकाधिक बिंदुओं द्वारा सेट किया जा सकता है और आप मान को पुनर्प्राप्त करने के बाद ही सत्यापित करते हैं, तो बग उस कोड में प्रतीत होता है जो अद्यतन करता है। यदि सेटर्स इनपुट को मान्य करते हैं, तो आप जानते हैं कि कौन सा कोड अमान्य मान सेट करने का प्रयास कर रहा है।
आप एरिक इवांस द्वारा Domain Driven Design को देखना चाहेंगे।
... स्पष्ट विधेय की तरह मान विशेष उद्देश्यों के लिए OBJECTS: DDD एक विशिष्टता की इस धारणा है। एक विनिर्देश एक विधेय कि निर्धारित करता है एक वस्तु करता है या कुछ मानदंडों को पूरा नहीं करता है तो है।
मुझे लगता है कि तेजी से असफल होना एक बात है, दूसरा यह है कि सत्यापन के लिए तर्क रखना है। डोमेन तर्क रखने के लिए सही जगह है और मुझे लगता है कि एक विशिष्टता ऑब्जेक्ट या आपके डोमेन ऑब्जेक्ट्स पर एक वैध विधि एक अच्छी जगह होगी।
मैं IDataErrorInfo को लागू करने और अपनी त्रुटि और इस [columnName] गुणों में मेरी मान्यता तर्क डाल करने के लिए पसंद करते हैं। इस तरह आप प्रोग्राम के रूप में जांच करने के लिए उसमें कोई त्रुटि तो आप बस कोड में उन गुणों के दोनों परीक्षण कर सकते हैं, या आप डेटा वेब फार्म, विण्डोज़ फॉर्म्स या WPF में बाध्यकारी के लिए रवाना सत्यापन हाथ कर सकते हैं कि चाहते हैं।
WPF के "ValidatesOnDataError" बाइंडिंग संपत्ति यह विशेष रूप से आसान बना देता है।
@Terrapin, पुन:
क्षेत्रों यदि आप केवल इतना है [सरल सार्वजनिक सेट/प्राप्त] गुणों का एक समूह है ... वे रूप में अच्छी तरह हो सकता है
गुण है खेतों में अन्य फायदे। वे एक अधिक स्पष्ट अनुबंध हैं, वे क्रमबद्ध हैं, उन्हें बाद में डीबग किया जा सकता है, वे विरासत के माध्यम से विस्तार के लिए एक अच्छी जगह हैं। क्लंकियर सिंटैक्स एक आकस्मिक जटिलता है - उदाहरण के लिए नेट 3.5 इस पर विजय प्राप्त करता है।
सार्वजनिक क्षेत्रों के साथ शुरू करना एक आम (और दोषपूर्ण) अभ्यास है, और उन्हें 'आवश्यकतानुसार' आधार पर बाद में गुणों में बदलना है। यह आपके अनुबंध को किसी भी व्यक्ति के साथ तोड़ देता है जो आपकी कक्षा का उपभोग करता है, इसलिए संपत्तियों से शुरू करना सबसे अच्छा है।
मैं कभी भी अपनी ऑब्जेक्ट्स को अमान्य स्थिति में प्रवेश करने की कोशिश नहीं करता, इसलिए सेटर्स निश्चित रूप से सत्यापन के साथ-साथ राज्य को बदलने वाली किसी भी विधि के पास भी होंगे। इस तरह, मुझे चिंता करने की ज़रूरत नहीं है कि जिस वस्तु से मैं निपट रहा हूं वह अमान्य है। यदि आप अपनी विधियों को सत्यापन सीमाओं के रूप में रखते हैं, तो आपको सत्यापन के ढांचे और IsValid() विधि कॉल के बारे में चिंता करने की ज़रूरत नहीं है, जो पूरे स्थान पर छिड़कते हैं।
आप विस्तार से बता सकते हैं? आप उदाहरण के एक अलग मान्यता विधि में <5 && > 0 के लिए जाँच के लिए कह रहे हैं? फिर आपके गेटर्स और सेटर्स वास्तव में क्या कर रहे हैं जो एक नियमित क्षेत्र नहीं है? –