2011-08-09 12 views
6

मैं इस सरल प्रश्न का उत्तर जानना चाहता हूं।इकाइयां नियम बनाना

जब मैं कोई इकाई ऑब्जेक्ट बनाता हूं और मैं एक विशेषता की सेटिंग को प्रतिबंधित करना चाहता हूं (उदाहरण के लिए मैं किसी को एक पूर्णांक मान को 1 से कम करने के लिए अनुमति नहीं देना चाहता), तो क्या इसे इसे लागू करना चाहिए इस विशेषता का सेटटर या क्या मुझे बाद में इस प्रतिबंध को उस वर्ग में जांचना चाहिए जो इन वस्तुओं को संभालता है? आम तौर पर, क्या मैं गेटर्स और सेटर्स को कार्यान्वित कर सकता हूं, हालांकि मैं तब तक चाहता हूं जब तक कि मेरे गेटर्स रिटर्न और सेटर्स गुण सेट न करें?

मुझे पता है कि जावा में कुछ नियम (कोड सम्मेलन) हैं, इसलिए मैं उनमें से किसी को तोड़ना नहीं चाहता हूं।

अग्रिम धन्यवाद, उम्मीद है कि मेरा प्रश्न पर्याप्त स्पष्ट है और किसी भी व्याकरण गलतियों के लिए खेद है जो मैंने किया होगा: /।

उत्तर

6

हाँ गेटर्स/सेटर्स इसके लिए उपयोगी हैं।

उदाहरण के लिए :

public void setAge(int age){ 
if(age < 0){ 
    throw new IllegalArgumentException("Invalid age : " + age); 
    //or if you don't want to throw an exception you can handle it otherways too 
} 
} 

तुम भी जावा ईई के Bean Validators उपयोग कर सकते हैं अपने प्रश्न की मेरी समझ से इस

public class Person{ 

    @Min(value = 0) 
    @Max(value = 99) 
    private Integer age; 

    //some other code 
} 
+0

धन्यवाद! आपकी मदद की बहुत सराहना की जाती है, और अन्य दृष्टिकोण के बारे में जानकर खुशी हुई :) – VaclavDedik

+0

आपका स्वागत है :) –

1

यह गेटर्स और सेटर्स का लक्ष्य है।

यदि हम इन तरीकों में कुछ व्यवहार नहीं जोड़ सकते हैं, तो ... हम सार्वजनिक विशेषताओं का उपयोग क्यों नहीं करते?

2

मेरे पसंदीदा दृष्टिकोण JSR 303 (बीन मान्यता एपीआई) का उपयोग करने के लिए सुनिश्चित करना है कि वर्ग के गुणों मान्य होते हैं।

सेटर्स में सत्यापन करने के लिए यह ठीक है, लेकिन यह हमेशा एक वांछनीय दृष्टिकोण नहीं है। एक दूसरे से संबंधित नहीं हैं कि कई संदर्भों की जरूरतों को मिश्रण करने की क्षमता है। उदाहरण के लिए, आपकी कुछ संपत्तियों को उपयोगकर्ता-इंटरफ़ेस से कभी भी सेट नहीं किया जाना चाहिए, और इसके बजाय जारी रखने से पहले, किसी सेवा द्वारा गणना की जाएगी। ऐसी घटना में, इस तर्क को एक सेटटर के अंदर रखना वांछनीय नहीं है, क्योंकि आपको उस संदर्भ को जानने की आवश्यकता होगी जिसमें सेटर को बुलाया जा रहा है; आपको अपनी यूआई परत और अपनी दृढ़ता परत में विभिन्न नियमों को लागू करने की आवश्यकता होगी। जेएसआर 303 आपको सत्यापन समूहों का उपयोग करके इन चिंताओं को अलग करने की अनुमति देता है, ताकि आपका यूआई सत्यापन समूह आपके दृढ़ता सत्यापन समूह से अलग हो।

जेपीए 2.0, जब आप बाधाओं है कि एक JSR 303 सत्यापनकर्ता द्वारा मूल्यांकन किया जाता है का उपयोग कर अपने वर्ग व्याख्या करते हैं, अपने हठ प्रदाता स्वचालित रूप से PrePersist, PreUpdate और PreRemove पर इन बाधाओं (आमतौर पर ऐसा नहीं किया, नीचे देखें) का मूल्यांकन कर सकते में के जीवन चक्र की घटनाओं संस्थाओं। अपने जेपीए प्रदाता में इकाइयों के सत्यापन को निष्पादित करने के लिए, आपको validation-mode तत्व या javax.persistence.validation.mode संपत्ति को persistence.xml फ़ाइल में निर्दिष्ट करना होगा; मान AUTO (डिफ़ॉल्ट) या CALLBACK (और NONE नहीं) होना चाहिए।

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

CALLBACK मोड आपको लाइफसाइक्ल ईवेंट ट्रिगर होने पर लागू होने वाले सत्यापन समूहों को ओवरराइड करने की अनुमति देगा। डिफ़ॉल्ट रूप से, डिफ़ॉल्ट बीन सत्यापन समूह (Default) अद्यतन और लगातार घटनाओं के लिए मान्य किया जाएगा; निकालने की घटना में कोई सत्यापन शामिल नहीं है। CALLBACK मोड आपको javax.persistence.validation.group.pre-persist, javax.persistence.validation.group.pre-update और javax.persistence.validation.group.pre-remove गुणों का उपयोग करके इन घटनाओं के लिए एक अलग सत्यापन समूह निर्दिष्ट करने की अनुमति देता है।

ध्यान रखें कि जेएसआर 303 सत्यापन जावा ईई कंटेनर के बाहर उपयोग किया जा सकता है, हालांकि ऊपर पोस्ट किया गया बीन सत्यापन एपीआई दस्तावेज लिंक जावा ईई 6 एपीआई दस्तावेज से है।

+0

बीटीडब्ल्यू, जेएसआर 303 का संदर्भ कार्यान्वयन हाइबरनेट वैलिडेटर फ्रेमवर्क है। देखें: http://www.hibernate.org/subprojects/validator.html – MicSim

0

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

एक और समाधान ऑब्जेक्ट सत्यापन (जेएसआर -303 कार्यान्वयन की तरह कुछ) का उपयोग करना होगा जो आपको फ़ील्ड को न्यूनतम और अधिकतम मानों के साथ एनोटेट करने की अनुमति देगा। जैसे

@Min(value=1) 
private int myvalue; 

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

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

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