जावा अनुप्रयोगों में मान्यता

यह पाठ डेटा सत्यापन के लिए विभिन्न दृष्टिकोणों को समर्पित है: जावा अनुप्रयोगों में डेटा को मान्य करते समय एक परियोजना पर क्या नुकसान हो सकता है और किन तरीकों और प्रौद्योगिकियों का पालन किया जाना चाहिए।

मैंने अक्सर ऐसी परियोजनाएँ देखीं जिनके रचनाकारों ने डेटा सत्यापन के लिए एक दृष्टिकोण चुनने की जहमत नहीं उठाई। टीमों ने समय सीमा और अस्पष्ट आवश्यकताओं के रूप में अविश्वसनीय दबाव में परियोजना पर काम किया, और परिणामस्वरूप, उनके पास सटीक, सुसंगत सत्यापन के लिए समय नहीं था। इसलिए, उनका सत्यापन कोड हर जगह बिखरा हुआ है: जावास्क्रिप्ट स्निपेट, स्क्रीन कंट्रोलर में, बिजनेस लॉजिक डिब्बे, डोमेन एंटिटीज़, ट्रिगर्स और डेटाबेस की कमी में। यह कोड if-else कथनों से भरा था, इसने अपवादों का एक गुच्छा फेंक दिया, और यह पता लगाने की कोशिश करें कि डेटा के उस विशेष टुकड़े को वहां मान्य किया गया है ... परिणामस्वरूप, जैसे ही परियोजना विकसित होती है, आवश्यकताओं का अनुपालन करना मुश्किल और महंगा हो जाता है (अक्सर काफी भ्रामक), और डेटा सत्यापन के लिए दृष्टिकोण की एकरूपता।

तो क्या डेटा को मान्य करने का कोई सरल और सुरुचिपूर्ण तरीका है? क्या कोई ऐसा तरीका है जो हमें अपठनीयता के पाप से बचाएगा, एक ऐसा तरीका जो सत्यापन के सभी तर्क को एक साथ रखेगा, और जो पहले से ही लोकप्रिय जावा फ्रेमवर्क के डेवलपर्स द्वारा हमारे लिए बनाया गया है?

हां, एक ऐसा तरीका है।

हमारे लिए, सीयूबीए मंच के डेवलपर्स, यह बहुत महत्वपूर्ण है कि आप सर्वोत्तम प्रथाओं का उपयोग कर सकते हैं। हमारा मानना ​​है कि सत्यापन कोड होना चाहिए:

1. पुन: प्रयोज्य बनें और DRY सिद्धांत का पालन करें;
2. स्वाभाविक और समझ में आता है;
3. जहां डेवलपर इसे देखने की उम्मीद करता है;
4. विभिन्न स्रोतों से डेटा को सत्यापित करने में सक्षम हो: उपयोगकर्ता इंटरफ़ेस, SOAP कॉल, REST, आदि।
5. समस्याओं के बिना एक बहु-थ्रेडेड वातावरण में काम करें;
6. मैन्युअल रूप से चेक चलाने की आवश्यकता के बिना, स्वचालित रूप से आवेदन के अंदर कॉल किया जाता है;
7. संक्षिप्त संवाद बॉक्स में उपयोगकर्ता को स्पष्ट, स्थानीय संदेश देने के लिए;
8. मानकों का पालन करें।

आइए देखते हैं कि CUBA प्लेटफ़ॉर्म फ्रेमवर्क का उपयोग करके लिखे गए एक उदाहरण एप्लिकेशन का उपयोग करके इसे कैसे लागू किया जा सकता है। हालाँकि, सीयूबीए स्प्रिंग और एक्लिप्सलिंक पर आधारित है, इसलिए यहां इस्तेमाल की जाने वाली अधिकांश तकनीकें किसी अन्य जावा प्लेटफॉर्म पर काम करेंगी जो जेपीए और बीन वैलिडेशन विनिर्देशों का समर्थन करता है।

डेटाबेस की कमी का उपयोग कर मान्यता

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

एक उदाहरण पर विचार करें, जो हम में से अधिकांश जानते हैं, कुछ अपने स्वयं के अनुभव से भी ... यदि विनिर्देश कहता है कि पासपोर्ट नंबर फ़ील्ड में 10 वर्ण होने चाहिए, तो यह बहुत संभव है कि यह सभी द्वारा जांचा जाएगा: DDL में एक DB वास्तुकार, इसी इकाई में एक बैकेंड डेवलपर और अन्य सेवाएं, और अंत में, UI डेवलपर सीधे क्लाइंट की तरफ। फिर यह आवश्यकता बदल जाती है, और क्षेत्र 15 वर्णों तक बढ़ जाता है। डेवोप्स डेटाबेस में बाधाओं को बदलते हैं, लेकिन उपयोगकर्ता के लिए कुछ भी नहीं बदलता है, क्योंकि क्लाइंट की ओर से बाधा समान है ...

कोई भी डेवलपर जानता है कि इस समस्या से कैसे बचा जाए - सत्यापन को केंद्रीकृत किया जाना चाहिए! CUBA में, JPA इकाई एनोटेशन में ऐसी मान्यता पाई जाती है। इस मेटा-जानकारी के आधार पर, सीयूबीए स्टूडियो सही डीडीएल स्क्रिप्ट उत्पन्न करेगा और उपयुक्त क्लाइंट-साइड सत्यापनकर्ता लागू करेगा।

यदि एनोटेशन बदलते हैं, तो CUBA DDL स्क्रिप्ट को अपडेट करेगा और माइग्रेशन स्क्रिप्ट को जेनरेट करेगा, इसलिए अगली बार जब आप प्रोजेक्ट परिनियोजित करेंगे, तो नए JPA- आधारित प्रतिबंध इंटरफ़ेस और एप्लिकेशन डेटाबेस में प्रभावी होंगे।

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

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

बीन सत्यापन

हर कोई जानता है कि लंबे जीवन चक्र वाले मानकों का पालन करना अच्छा है, जिसकी प्रभावशीलता हजारों परियोजनाओं पर साबित हुई है। जावा बीन वैलिडेशन JSR 380, 349, और 303 और उनके अनुप्रयोगों में प्रलेखित है: हाइबरनेट वैलिडेटर और अपाचे बीवीएल ।

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

बीन वैलिडेशन का उपयोग करने से परियोजना को कई फायदे मिलते हैं:

• सत्यापन तर्क विषय क्षेत्र के बगल में स्थित है: बिन के क्षेत्रों और तरीकों के लिए प्रतिबंधों की परिभाषा एक प्राकृतिक और सही मायने में वस्तु-उन्मुख तरीके से होती है।
• बीन सत्यापन मानक हमें बॉक्स के बाहर दर्जनों सत्यापन एनोटेशन देता है, उदाहरण के लिए: @Size , @Min , @Max , @Pattern , @Email , @Past , काफी मानक @URL , @Length , सबसे शक्तिशाली @ScriptAssert और कई अन्य ।
• मानक हमें तैयार किए गए एनोटेशन तक सीमित नहीं करता है और हमें अपना स्वयं का निर्माण करने की अनुमति देता है। हम कई अन्य लोगों को मिलाकर एक नया एनोटेशन भी बना सकते हैं, या एक सत्यापनकर्ता के रूप में एक अलग जावा वर्ग का उपयोग करके इसे परिभाषित कर सकते हैं।
  उदाहरण के लिए, उपरोक्त उदाहरण में, हम यह सत्यापित करने के लिए @ValidPassportNumber वर्ग का स्तर एनोटेशन सेट कर सकते हैं कि पासपोर्ट नंबर country क्षेत्र के मूल्य के आधार पर प्रारूप से मेल खाता है।
• बाधाओं को न केवल खेतों या वर्गों पर, बल्कि विधियों और उनके मापदंडों पर भी सेट किया जा सकता है। इस दृष्टिकोण को "अनुबंध द्वारा सत्यापन" कहा जाता है और थोड़ी देर बाद चर्चा की जाएगी।

जब उपयोगकर्ता दर्ज की गई जानकारी को सबमिट करता है, तो CUBA प्लेटफॉर्म (कुछ अन्य फ्रेमवर्क की तरह) बीन वैलिडेशन स्वचालित रूप से शुरू हो जाता है, इसलिए यह तुरंत एक त्रुटि संदेश प्रदर्शित करता है यदि सत्यापन विफल हो जाता है, और हमें बिन सत्यापनकर्ता को मैन्युअल रूप से चलाने की आवश्यकता नहीं है।

आइए हम पासपोर्ट नंबर के साथ उदाहरण पर लौटते हैं, लेकिन इस बार हम इसे व्यक्तिगत इकाई के कई प्रतिबंधों के साथ पूरक करेंगे:

• name फ़ील्ड 2 या अधिक वर्ण का होना चाहिए और मान्य होना चाहिए। (जैसा कि आप देख सकते हैं, regexp सरल नहीं है, लेकिन "चार्ल्स ओगियर डे बत्त्ज़ डे Castelmore Comte d'Artagnan" परीक्षा पास करेगा, लेकिन "R2D2" नहीं करेगा);
• height (ऊंचाई) निम्नलिखित अंतराल में होनी चाहिए: 0 < height <= 300 सेमी;
• email फ़ील्ड में एक स्ट्रिंग होनी चाहिए जो सही ईमेल के प्रारूप से मेल खाती हो।

इन सभी जांचों के साथ, व्यक्ति वर्ग इस तरह दिखाई देगा:

 @Listeners("passportnumber_PersonEntityListener") @NamePattern("%s|name") @Table(name = "PASSPORTNUMBER_PERSON") @Entity(name = "passportnumber$Person") @ValidPassportNumber(groups = {Default.class, UiCrossFieldChecks.class}) @FraudDetectionFlag public class Person extends StandardEntity { private static final long serialVersionUID = -9150857881422152651L; @Pattern(message = "Bad formed person name: ${validatedValue}", regexp = "^[AZ][az]*(\\s(([az]{1,3})|(([az]+\\')?[AZ][az]*)))*$") @Length(min = 2) @NotNull @Column(name = "NAME", nullable = false) protected String name; @Email(message = "Email address has invalid format: ${validatedValue}", regexp = "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$") @Column(name = "EMAIL", length = 120) protected String email; @DecimalMax(message = "Person height can not exceed 300 centimeters", value = "300") @DecimalMin(message = "Person height should be positive", value = "0", inclusive = false) @Column(name = "HEIGHT") protected BigDecimal height; @NotNull @Column(name = "COUNTRY", nullable = false) protected Integer country; @NotNull @Column(name = "PASSPORT_NUMBER", nullable = false, length = 15) protected String passportNumber; ... } 

Person.java

मेरा मानना ​​है कि @DecimalMin , @Length , @Pattern , @Pattern और जैसे एनोटेशन का उपयोग काफी स्पष्ट है और इसमें कोई टिप्पणी नहीं करने की आवश्यकता है। आइए @ValidPassportNumber एनोटेशन के कार्यान्वयन पर करीब से नज़र डालें।

हमारा ब्रांड नया @ValidPassportNumber जाँचता है कि Person#passportNumber देश के प्रत्येक देश के लिए regexp पैटर्न से मेल खाता है।

पहले, आइए दस्तावेज़ीकरण देखें ( सीयूबीए या हाइबरनेट मैनुअल ठीक हैं), इसके अनुसार, हमें अपनी कक्षा को इस नए एनोटेशन के साथ चिह्नित करना होगा और groups पैरामीटर को इसके पास करना होगा, जहां UiCrossFieldChecks.class अर्थ है कि यह मान्यता क्रॉस पर चलाई जानी चाहिए सत्यापन - सभी व्यक्तिगत क्षेत्रों की जाँच करने के बाद, और Default.class डिफ़ॉल्ट सत्यापन समूह में प्रतिबंध को बचाता है।

एनोटेशन विवरण इस तरह दिखता है:

 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Constraint(validatedBy = ValidPassportNumberValidator.class) public @interface ValidPassportNumber { String message() default "Passport number is not valid"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; } 

ValidPassportNumber.java

यहां @Target(ElementType.TYPE) कहना है कि इस रनटाइम एनोटेशन का उद्देश्य वर्ग है, और @Constraint(validatedBy = … ) निर्धारित करता है कि सत्यापन ValidPassportNumberValidator वर्ग द्वारा किया जाता है जो ValidPassportNumberValidator ConstraintValidator<...> इंटरफ़ेस को लागू करता है। सत्यापन कोड स्वयं isValid(...) विधि में है, जो वास्तविक सत्यापन को सरल तरीके से करता है:

 public class ValidPassportNumberValidator implements ConstraintValidator<ValidPassportNumber, Person> { public void initialize(ValidPassportNumber constraint) { } public boolean isValid(Person person, ConstraintValidatorContext context) { if (person == null) return false; if (person.country == null || person.passportNumber == null) return false; return doPassportNumberFormatCheck(person.getCountry(), person.getPassportNumber()); } private boolean doPassportNumberFormatCheck(CountryCode country, String passportNumber) { ... } } 

ValidPassportNumberValidator.java

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

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

एक सुंदर समाधान नहीं है? आपको विषय क्षेत्र की संस्थाओं में केवल कुछ ही जावा एनोटेशन जोड़कर UI में सत्यापन त्रुटियों का पर्याप्त प्रदर्शन मिलता है।

अनुभाग को संक्षेप में बताने के लिए, आइए एक बार फिर से संस्थाओं के लिए बीन सत्यापन के फायदों की सूची दें:

1. यह समझने योग्य और पठनीय है;
2. आपको इकाई वर्गों में सीधे मूल्य बाधाओं को परिभाषित करने की अनुमति देता है;
3. यह अनुकूलित और पूरक किया जा सकता है;
4. डेटाबेस में सहेजे जाने से पहले लोकप्रिय ओआरएम में एकीकृत, और चेक स्वचालित रूप से चलाए जाते हैं;
5. जब उपयोगकर्ता यूआई को डेटा भेजता है (और यदि नहीं, तो मैन्युअल रूप से Validator इंटरफ़ेस को कॉल करना आसान है) कुछ फ्रेम बीन सत्यापन स्वचालित रूप से चलते हैं;
6. बीन सत्यापन एक मान्यता प्राप्त मानक है और इंटरनेट पर प्रलेखन से भरा है।

लेकिन क्या होगा यदि आपको किसी बाहरी सिस्टम से आने वाले डेटा को मान्य करने के लिए किसी विधि, कंस्ट्रक्टर या REST पते पर प्रतिबंध लगाने की आवश्यकता है? या यदि आपको प्रत्येक विधि में परीक्षण किए जा रहे कई और शर्तों के साथ उबाऊ कोड लिखे बिना, विधि मापदंडों के मूल्यों की घोषणा करने की आवश्यकता है?

उत्तर सरल है: बीन सत्यापन तरीकों पर भी लागू होता है!

अनुबंध द्वारा मान्यता

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

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

1. मैन्युअल रूप से अनिवार्य शैली में जांच करना आवश्यक नहीं है (उदाहरण के लिए, IllegalArgumentException और इसी तरह फेंककर)। आप घोषित रूप से बाधाओं को परिभाषित कर सकते हैं, और कोड को अधिक समझ और अभिव्यंजक बना सकते हैं;
2. बाधाओं को कॉन्फ़िगर, पुन: उपयोग और कॉन्फ़िगर किया जा सकता है: आपको प्रत्येक चेक के लिए सत्यापन तर्क लिखने की आवश्यकता नहीं है। कम कोड का मतलब है कम कीड़े।
3. यदि वर्ग, विधि या उसके पैरामीटर के रिटर्न मान को @Validated के साथ चिह्नित किया जाता है, तो प्लेटफ़ॉर्म द्वारा हर बार विधि को कॉल करने पर चेक स्वचालित रूप से किया जाएगा।
4. यदि निष्पादन योग्य को @Documented एनोटेशन के साथ चिह्नित किया गया है, तो इसके प्री- और पोस्टकॉन्डिशन जेनरेट किए गए JavaCoc में शामिल किए जाएंगे।

'अनुबंध सत्यापन' का उपयोग करके हम स्पष्ट, कॉम्पैक्ट और आसानी से बनाए रखा कोड प्राप्त करते हैं।

एक उदाहरण के लिए, आइए एक CUBA एप्लिकेशन के REST कंट्रोलर के इंटरफेस को देखें। PersonApiService इंटरफ़ेस आपको getPersons() विधि का उपयोग करके डेटाबेस से लोगों की एक सूची प्राप्त करने और addNewPerson(...) कॉल का उपयोग करके एक नया व्यक्ति जोड़ने की addNewPerson(...) ।

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

 @Validated public interface PersonApiService { String NAME = "passportnumber_PersonApiService"; @NotNull @Valid @RequiredView("_local") List<Person> getPersons(); void addNewPerson( @NotNull @Length(min = 2, max = 255) @Pattern(message = "Bad formed person name: ${validatedValue}", regexp = "^[AZ][az]*(\\s(([az]{1,3})|(([az]+\\')?[AZ][az]*)))*$") String name, @DecimalMax(message = "Person height can not exceed 300 cm", value = "300") @DecimalMin(message = "Person height should be positive", value = "0", inclusive = false) BigDecimal height, @NotNull CountryCode country, @NotNull String passportNumber ); } 

PersonApiService.java

क्या यह कोड पर्याप्त है?
_ (एनोटेशन @RequiredView(“_local”) को छोड़कर, CUBA प्लेटफ़ॉर्म के लिए विशिष्ट और यह सत्यापित करते हुए कि लौटी हुई Person ऑब्जेक्ट में PASSPORTNUMBER_PERSON टेबल से सभी फ़ील्ड शामिल हैं।)

@Valid परिभाषित करती है कि प्रत्येक संग्रह ऑब्जेक्ट getPersons() विधि द्वारा लौटाया जाना चाहिए, वह भी Person वर्ग के प्रतिबंधों के विरुद्ध मान्य होना चाहिए।

CUBA एप्लिकेशन में, ये विधियाँ निम्न पते पर उपलब्ध हैं:

• / app / बाकी / v2 / सेवाओं / passportnumber_PersonApiService / getPersons
• / app / बाकी / v2 / सेवाओं / passportnumber_PersonApiService / addNewPerson

आइए, डाकिया आवेदन खोलें और सुनिश्चित करें कि सत्यापन कार्य करना चाहिए:

जैसा कि आपने देखा होगा कि पासपोर्ट संख्या ऊपर के उदाहरण में मान्य नहीं है। ऐसा इसलिए है क्योंकि इस क्षेत्र को addNewPerson विधि के मापदंडों के क्रॉस-चेक की आवश्यकता होती है, क्योंकि passportNumber को मान्य करने के लिए एक नियमित अभिव्यक्ति टेम्पलेट की पसंद country क्षेत्र के मूल्य पर निर्भर करती है। यह क्रॉस-मान्यता वर्ग-स्तरीय इकाई प्रतिबंधों का एक पूर्ण एनालॉग है!

मापदंडों का क्रॉस-सत्यापन जेएसआर 349 और 380 द्वारा समर्थित है। आप वर्ग / इंटरफ़ेस विधियों के अपने स्वयं के क्रॉस-सत्यापन को कैसे लागू करें, यह जानने के लिए हाइबरनेट प्रलेखन पढ़ सकते हैं।

बीन के बाहर सत्यापन

दुनिया में पूर्णता नहीं है, इसलिए सेम सत्यापन की अपनी कमियां और सीमाएं हैं:

1. कभी-कभी हमें डेटाबेस में परिवर्तन करने से पहले वस्तुओं के एक जटिल ग्राफ की स्थिति की जांच करने की आवश्यकता होती है। उदाहरण के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि ग्राहक आदेश के सभी तत्व एक पैकेज में रखे गए हैं। यह एक कठिन प्रक्रिया है, और हर बार उपयोगकर्ता द्वारा नई वस्तुओं को ऑर्डर में जोड़ना एक अच्छा विचार नहीं है। इसलिए, इस तरह के चेक की आवश्यकता केवल एक बार हो सकती है: डेटाबेस में Order ऑब्जेक्ट और उसके OrderItem सबोबिज को सेव करने से पहले।
2. कुछ चेक एक लेनदेन के अंदर किए जाने की आवश्यकता है। उदाहरण के लिए, इलेक्ट्रॉनिक स्टोर सिस्टम को यह जांचना चाहिए कि डेटाबेस में ऑर्डर करने से पहले ऑर्डर पूरा करने के लिए सामान की पर्याप्त प्रतियां हैं या नहीं। ऐसा चेक केवल एक लेनदेन के अंदर ही किया जा सकता है, क्योंकि सिस्टम बहु-थ्रेडेड है और स्टॉक में माल की मात्रा किसी भी समय बदल सकती है।

CUBA प्लेटफ़ॉर्म दो पूर्व-प्रतिबद्ध डेटा सत्यापन तंत्र प्रदान करता है जिसे इकाई श्रोता और लेन-देन श्रोता कहते हैं । आइए उन पर अधिक विस्तार से विचार करें।

इकाई सूचीबद्घ

CUBA में एंटिटी श्रोता PreInsertEvent , PreUpdateEvent और PredDeleteEvent श्रोताओं से बहुत मिलते-जुलते हैं जो JPA डेवलपर को प्रदान करता है। दोनों तंत्र आपको डेटाबेस में संग्रहीत होने से पहले और बाद में इकाई वस्तुओं की जांच करने की अनुमति देते हैं।

CUBA में, एक इकाई श्रोता बनाना और कनेक्ट करना आसान है, इसके लिए आपको दो चीजों की आवश्यकता है:

1. एक प्रबंधित बीन बनाएँ जो कि एक श्रोता के इंटरफेस को लागू करता है। सत्यापन के लिए 3 इंटरफेस महत्वपूर्ण हैं:
   BeforeDeleteEntityListener<T>
BeforeInsertEntityListener<T>
BeforeUpdateEntityListener<T>
2. उस इकाई ऑब्जेक्ट पर @Listeners एनोटेशन जोड़ें जिसे आप ट्रैक करने की योजना बनाते हैं।

और वह सब है।

जेपीए मानक (जेएसआर 338, धारा 3.5) की तुलना में, सीयूबीए प्लेटफ़ॉर्म श्रोता इंटरफेस टाइप किए जाते हैं, इसलिए आपको इसके साथ काम करना शुरू करने के लिए किसी Object के प्रकार का तर्क देने की आवश्यकता नहीं है। CUBA प्लेटफॉर्म संबंधित संस्थाओं या EntityManager को जोड़ता है जो अन्य संस्थाओं को लोड और संशोधित करने की क्षमता रखता है। ये सभी परिवर्तन संबंधित निकाय श्रोता को भी आमंत्रित करेंगे।

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

आइए एक उदाहरण देखें। यहाँ, ईवेंट श्रोता बीन कोड की केवल एक पंक्ति के साथ इकाई वर्ग से जुड़ता है: @Listeners एनोटेशन, जो श्रोता वर्ग का नाम लेता है:

 @Listeners("passportnumber_PersonEntityListener") @NamePattern("%s|name") @Table(name = "PASSPORTNUMBER_PERSON") @Entity(name = "passportnumber$Person") @ValidPassportNumber(groups = {Default.class, UiCrossFieldChecks.class}) @FraudDetectionFlag public class Person extends StandardEntity { ... } 

Person.java

श्रोता कार्यान्वयन खुद इस तरह दिखता है:

 /** * Checks that there are no other persons with the same * passport number and country code * Ignores spaces in the passport number for the check. * So numbers "12 45 768007" and "1245 768007" and "1245768007" * are the same for the validation purposes. */ @Component("passportnumber_PersonEntityListener") public class PersonEntityListener implements BeforeDeleteEntityListener<Person>, BeforeInsertEntityListener<Person>, BeforeUpdateEntityListener<Person> { @Override public void onBeforeDelete(Person person, EntityManager entityManager) { if (!checkPassportIsUnique(person.getPassportNumber(), person.getCountry(), entityManager)) { throw new ValidationException( "Passport and country code combination isn't unique"); } } @Override public void onBeforeInsert(Person person, EntityManager entityManager) { // use entity argument to validate the Person object // entityManager could be used to access database // if you need to check the data // throw ValidationException object if validation check failed if (!checkPassportIsUnique(person.getPassportNumber(), person.getCountry(), entityManager)) throw new ValidationException( "Passport and country code combination isn't unique"); } @Override public void onBeforeUpdate(Person person, EntityManager entityManager) { if (!checkPassportIsUnique(person.getPassportNumber(), person.getCountry(), entityManager)) throw new ValidationException( "Passport and country code combination isn't unique"); } ... } 

PersonEntityListener.java

अगर एक बहुत अच्छा विकल्प है तो श्रोता श्रोता हैं:

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

लेन-देन सुनने वाले

सीयूबीए लेनदेन श्रोता लेनदेन के संदर्भ में भी कार्य करते हैं, लेकिन, इकाई श्रोताओं की तुलना में, उन्हें प्रत्येक डेटाबेस लेनदेन के लिए बुलाया जाता है।

ये उन्हें सुपर पावर देते हैं:

• कुछ भी उनके ध्यान से बच नहीं सकता।

लेकिन वही उनकी कमियों से निर्धारित होता है:

• उन्हें लिखना अधिक कठिन है;
• वे प्रदर्शन को काफी कम कर सकते हैं;
• उन्हें बहुत सावधानी से लिखा जाना चाहिए: लेनदेन के श्रोता में एक बग आवेदन के प्रारंभिक लोडिंग में भी हस्तक्षेप कर सकता है।

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

एक नमूने पर नज़र डालें जो यह देखने के लिए जांचता है कि क्या इकाई में @FraudDetectionFlag एनोटेशन है, और यदि कोई है, तो एक धोखाधड़ी डिटेक्टर शुरू करता है। मैं दोहराता हूं: ध्यान रखें कि प्रत्येक डेटाबेस लेनदेन करने से पहले इस पद्धति को सिस्टम पर कॉल किया जाता है, इसलिए कोड को संभव के रूप में कुछ ऑब्जेक्ट्स की जांच करने का प्रयास करना चाहिए।

 @Component("passportnumber_ApplicationTransactionListener") public class ApplicationTransactionListener implements BeforeCommitTransactionListener { private Logger log = LoggerFactory.getLogger(ApplicationTransactionListener.class); @Override public void beforeCommit(EntityManager entityManager, Collection<Entity> managedEntities) { for (Entity entity : managedEntities) { if (entity instanceof StandardEntity && !((StandardEntity) entity).isDeleted() && entity.getClass().isAnnotationPresent(FraudDetectionFlag.class) && !fraudDetectorFeedAndFastCheck(entity)) { logFraudDetectionFailure(log, entity); String msg = String.format( "Fraud detection failure in '%s' with id = '%s'", entity.getClass().getSimpleName(), entity.getId()); throw new ValidationException(msg); } } } ... } 

ApplicationTransactionListener.java

एक लेन-देन श्रोता बनने के लिए, एक प्रबंधित बीन को पहले BeforeCommitTransactionListener इंटरफ़ेस और पहले beforeCommit विधि लागू करनी चाहिए। जब एप्लिकेशन शुरू होता है तो लेन-देन सुनने वाले अपने आप बंध जाते हैं। BeforeCommitTransactionListener सभी वर्गों को पंजीकृत करता है जो लेनदेन श्रोताओं के रूप में पहले BeforeCommitTransactionListener या AfterCompleteTransactionListener को लागू BeforeCommitTransactionListener ।

निष्कर्ष

बीन सत्यापन (जेपीए 303, 349 और 980) एक दृष्टिकोण है जो एक कॉर्पोरेट परियोजना में सामना किए गए डेटा सत्यापन मामलों के 95% के लिए विश्वसनीय आधार के रूप में काम कर सकता है। इस दृष्टिकोण का मुख्य लाभ यह है कि अधिकांश सत्यापन तर्क सीधे डोमेन मॉडल कक्षाओं में केंद्रित है। इसलिए, इसे खोजना आसान है, पढ़ना आसान है और बनाए रखना आसान है। स्प्रिंग, सीयूबीए और कई अन्य पुस्तकालय इन मानकों का समर्थन करते हैं और स्वचालित रूप से यूआई परत पर डेटा प्राप्त करते समय मान्य जांच करते हैं, मान्य तरीकों को कॉल करते हैं, या ओआरएम के माध्यम से डेटा संग्रहीत करते हैं, इसलिए बीन सत्यापन अक्सर डेवलपर के दृष्टिकोण से जादू जैसा दिखता है।

कुछ सॉफ्टवेयर डेवलपर्स विषय मॉडल की कक्षाओं के स्तर पर सत्यापन को अप्राकृतिक और बहुत जटिल के रूप में देखते हैं, वे कहते हैं कि यूआई स्तर पर डेटा सत्यापन एक काफी प्रभावी रणनीति है। हालांकि, मेरा मानना ​​है कि घटकों और यूआई नियंत्रकों में कई सत्यापन बिंदु सबसे तर्कसंगत दृष्टिकोण नहीं हैं। , , , , , listener' .

, , :

1. JPA , , DDL.
2. Bean Validation — , , , . , .
3. bean validation, . , , REST.
4. Entity listeners: , Bean Validation, . , . Hibernate .
5. Transaction listeners — , , . , , .

PS: , Java, , , .

उपयोगी लिंक