सत्यापनकर्ता + पहलू: सत्यापन को अनुकूलित करें

शुभ दिन, हेब्र!

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

समस्या

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

इसलिए, यह मानक सत्यापनकर्ताओं को खींचने का एक तरीका खोजने का निर्णय लिया गया जहां आवश्यक हो, और न केवल नियंत्रक में।

हम सत्यापनकर्ताओं को खींचते हैं

Google में खुदाई के कुछ घंटों के बाद, कुछ समाधान पाए गए, जिनमें से सबसे पर्याप्त था javax.validation.Validator को ऑटोवॉयर करना और उस पर मान्य विधि को कॉल करना, जिसके लिए आपको एक पैरामीटर के रूप में एक वैध ऑब्जेक्ट पास करने की आवश्यकता होती है।

ऐसा लगता है कि एक समाधान मिल गया है, लेकिन हर जगह मान्य करने के लिए सत्यापनकर्ता एक अच्छा विचार नहीं लगता है, मैं एक और अधिक सुंदर समाधान चाहता था।

AOP जोड़ें

दो बार सोचने के बिना, मैंने इस समाधान के लिए अपने पसंदीदा पहलुओं को अनुकूलित करने का प्रयास करने का फैसला किया।

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

तो एनोटेशन:

//      @Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Validate {} 

प्रश्नों को परिवर्तित करने की एक विधि है:

 @Validate public SomeBankRequest requestToBankRequest(Request<T> request) { SomeBankRequest bankRequest = ...; ... //        ... return bankRequest; } 

ठीक है, वास्तव में पहलू ही:

 @Aspect @Component public class ValidationAspect { private final Validator validator; //    public ValidationAspect(Validator validator) { this.validator = validator; } //       // @Validate       @AfterReturning(pointcut = "@annotation(api.annotations.Validate)", returning = "result") public void validate(JoinPoint joinPoint, Object result) { //     Set<ConstraintViolation<Object>> violations = validator.validate(result); //    ,    ,     //        if (!violations.isEmpty()) { StringBuilder builder = new StringBuilder(); //          ,   //  violations.forEach(violation -> builder .append(violation.getPropertyPath()) .append("[" + violation.getMessage() + "],")); throw new IllegalArgumentException("Invalid values for fields: " + builder.toString()); } } } 

काम के पहलू के बारे में संक्षेप में:

हम मान्य विधि से लौटाए गए ऑब्जेक्ट को इंटरसेप्ट करते हैं, फिर इसे सत्यापनकर्ता विधि से पास करते हैं, जो वापस Set<ConstraintViolation<Object>> करेगा Set<ConstraintViolation<Object>> - संक्षेप में - मान्य फ़ील्ड और त्रुटियों के साथ अलग-अलग जानकारी वाली कक्षाओं का एक सेट। यदि कोई त्रुटि नहीं हैं, तो सेट खाली हो जाएगा। फिर हम सिर्फ सेट के माध्यम से जाते हैं और एक त्रुटि संदेश बनाते हैं, जिसमें सभी फ़ील्ड मान्य नहीं हैं, और निष्पादन को फेंक देते हैं।

 violation.getPropertyPath() -    violation.getMessage() -  ,       

निष्कर्ष

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

पुनश्च

इसके अलावा, यदि आप एक विधि को उसी वर्ग की किसी अन्य विधि से मान्य कहते हैं, तो अनूप और प्रॉक्सी के बीच संबंध को याद रखें।