🤴🏾 ✊🏽 🕙 स्प्रिंग एनोटेशन: एओपी मैजिक 👧🏼 🌾 🐣

एनोटेशन कैसे काम करता है इसकी पवित्र जानकारी हर किसी के लिए सुलभ नहीं है। ऐसा लगता है कि यह किसी प्रकार का जादू है: मैंने विधि / क्षेत्र / वर्ग पर एक कुत्ते के साथ एक जादू कर दिया - और तत्व अपने गुणों को बदलना शुरू कर देता है और नए प्राप्त करता है।

आज हम स्प्रिंग एनोटेशन का उपयोग करके एनोटेशन के जादू को एक उदाहरण के रूप में जानेंगे: सेम फ़ील्ड को इनिशियलाइज़ करना।

हमेशा की तरह, लेख के अंत में GitHub पर परियोजना का एक लिंक है, जिसे डाउनलोड किया जा सकता है और देखें कि सब कुछ कैसे काम करता है।

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

परियोजना में, हमें संबंधित संस्थाओं और डीटीओ के एक जोड़े की आवश्यकता है। मैं चुनिंदा रूप से एक जोड़ी दूंगा।

ग्रह

@Entity @Table(name = "planets") @EqualsAndHashCode(callSuper = false) @Setter @AllArgsConstructor @NoArgsConstructor public class Planet extends AbstractEntity { private String name; private List<Continent> continents; @Column(name = "name") public String getName() { return name; } @OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL, mappedBy = "planet") public List<Continent> getContinents() { return continents; } }

PlanetDto

 @EqualsAndHashCode(callSuper = true) @Data public class PlanetDto extends AbstractDto { private String name; private List<ContinentDto> continents; }

मैपर। इसे इस तरह से व्यवस्थित क्यों किया गया है, यह इसी लेख में वर्णित है।

EntityDtoMapper

 public interface EntityDtoMapper<E extends AbstractEntity, D extends AbstractDto> { E toEntity(D dto); D toDto(E entity); }

AbstractMapper

 @Setter public abstract class AbstractMapper<E extends AbstractEntity, D extends AbstractDto> implements EntityDtoMapper<E, D> { @Autowired ModelMapper mapper; private Class<E> entityClass; private Class<D> dtoClass; AbstractMapper(Class<E> entityClass, Class<D> dtoClass) { this.entityClass = entityClass; this.dtoClass = dtoClass; } @PostConstruct public void init() { } @Override public E toEntity(D dto) { return Objects.isNull(dto) ? null : mapper.map(dto, entityClass); } @Override public D toDto(E entity) { return Objects.isNull(entity) ? null : mapper.map(entity, dtoClass); } Converter<E, D> toDtoConverter() { return context -> { E source = context.getSource(); D destination = context.getDestination(); mapSpecificFields(source, destination); return context.getDestination(); }; } Converter<D, E> toEntityConverter() { return context -> { D source = context.getSource(); E destination = context.getDestination(); mapSpecificFields(source, destination); return context.getDestination(); }; } void mapSpecificFields(E source, D destination) { } void mapSpecificFields(D source, E destination) { } }

PlanetMapper

 @Component public class PlanetMapper extends AbstractMapper<Planet, PlanetDto> { PlanetMapper() { super(Planet.class, PlanetDto.class); } }

फ़ील्ड इनिशियलाइज़ेशन।

अमूर्त मैपर क्लास में क्लास क्लास में दो फील्ड होते हैं जिन्हें हमें इम्प्लीमेंटेशन में इनिशियलाइज़ करना होता है।

  private Class<E> entityClass; private Class<D> dtoClass;

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

शुरुआत करने के लिए, एनोटेशन स्वयं लिखें। कोई अतिरिक्त निर्भरता जोड़ने की आवश्यकता नहीं है।

मैजिक डॉग को क्लास के सामने पेश करने के लिए, हम निम्नलिखित लिखेंगे:

 @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE}) @Documented public @interface Mapper { Class<?> entity(); Class<?> dto(); }

@ रिटेंशन (RetentionPolicy.RUNTIME) - नीति को परिभाषित करता है कि संकलन करते समय एनोटेशन का पालन होगा। उनमें से तीन हैं:

स्रोत - संकलन के दौरान इस तरह के एनोटेशन को ध्यान में नहीं रखा जाएगा। यह विकल्प हमें शोभा नहीं देता।

CLASS - एनोटेशन संकलन पर लागू किया जाएगा। यह विकल्प है
डिफ़ॉल्ट नीति।

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

लक्ष्य ({ElementType.TYPE}) - परिभाषित करता है कि इस एनोटेशन को किस आधार पर लटकाया जा सकता है। यह एक क्लास, मेथड, फील्ड, कंस्ट्रक्टर, लोकल वैरिएबल, पैरामीटर, वगैरह - सिर्फ 10 ऑप्शन हो सकते हैं। हमारे मामले में, TYPE का मतलब एक वर्ग (इंटरफ़ेस) है।

एनोटेशन में, हम खेतों को परिभाषित करते हैं। फ़ील्ड में डिफ़ॉल्ट मान हो सकते हैं (डिफ़ॉल्ट "डिफ़ॉल्ट फ़ील्ड", उदाहरण के लिए), फिर उन्हें भरने की संभावना नहीं है। यदि कोई डिफ़ॉल्ट मान नहीं हैं, तो फ़ील्ड भरना होगा।

अब मैपर के हमारे कार्यान्वयन पर एक टिप्पणी डालते हैं और खेतों में भरते हैं।

 @Component @Mapper(entity = Planet.class, dto = PlanetDto.class) public class PlanetMapper extends AbstractMapper<Planet, PlanetDto> {

हमने बताया कि हमारे मैपर का सार Planet.class है, और DTO PlanetDto.class है।

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

postProcessBeforeInitialization () - बीन को इनिशियलाइज़ करने से पहले निष्पादित किया जाता है।

postProcessAfterInitialization () - बीन इनिशियलाइजेशन के बाद निष्पादित।

इस प्रक्रिया को प्रसिद्ध स्प्रिंग-रिपर एवेगी बोरिसोव के वीडियो में और अधिक विस्तार से वर्णित किया गया है, जिसे कहा जाता है: "एवगेनी बोरिसोव - स्प्रिंग-रिपर।" मैं देखने की सलाह देता हूं।

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

ऐसा करने के लिए, हम एक MapperAnnotationProcessor बनाते हैं (स्प्रिंग के नियमों के अनुसार, सभी एनोटेशन प्रोसेसर को ... एनोटेशनप्रोसेसर में समाप्त होना चाहिए) और इसे बीनपोस्टप्रोसेसर से विरासत में मिला। ऐसा करने के लिए, हमें उन दो विधियों को ओवरराइड करना होगा।

 @Component public class MapperAnnotationProcessor implements BeanPostProcessor { @Override public Object postProcessBeforeInitialization(@Nullable Object bean, String beanName) { return Objects.nonNull(bean) ? init(bean) : null; } @Override public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) { return bean; } }

यदि कोई बिन है, तो हम इसे एनोटेशन मापदंडों के साथ आरंभ करते हैं। हम इसे एक अलग तरीके से करेंगे। सबसे आसान तरीका:

  private Object init(Object bean) { Class<?> managedBeanClass = bean.getClass(); Mapper mapper = managedBeanClass.getAnnotation(Mapper.class); if (Objects.nonNull(mapper)) { ((AbstractMapper) bean).setEntityClass(mapper.entity()); ((AbstractMapper) bean).setDtoClass(mapper.dto()); } return bean; }

बिन आरंभीकरण के दौरान, हम उनके माध्यम से चलते हैं और यदि हम बिन के ऊपर मैपर एनोटेशन पाते हैं, तो हम बिन क्षेत्रों को एनोटेशन मापदंडों के साथ आरंभ करते हैं।

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

सब कुछ सही करने का काम मुश्किल है, लेकिन संभव है।

वसंत में एक महान परावर्तनशील घटक है जो आपको सबसे सुरक्षित तरीके से प्रतिबिंब के साथ काम करने की अनुमति देता है। और हम इसके माध्यम से क्षेत्र की कक्षाओं को निर्धारित करेंगे।

हमारी init () विधि इस तरह दिखाई देगी:

  private Object init(Object bean) { Class<?> managedBeanClass = bean.getClass(); Mapper mapper = managedBeanClass.getAnnotation(Mapper.class); if (Objects.nonNull(mapper)) { ReflectionUtils.doWithFields(managedBeanClass, field -> { assert field != null; String fieldName = field.getName(); if (!fieldName.equals("entityClass") && !fieldName.equals("dtoClass")) { return; } ReflectionUtils.makeAccessible(field); Class<?> targetClass = fieldName.equals("entityClass") ? mapper.entity() : mapper.dto(); Class<?> expectedClass = Stream.of(ResolvableType.forField(field).getGenerics()).findFirst() .orElseThrow(() -> new IllegalArgumentException("Unable to get generic type for " + fieldName)).resolve(); if (expectedClass != null && !expectedClass.isAssignableFrom(targetClass)) { throw new IllegalArgumentException(String.format("Unable to assign Class %s to expected Class %s", targetClass, expectedClass)); } field.set(bean, targetClass); }); } return bean; }

जैसे ही हमें पता चलता है कि हमारे घटक को मैपर एनोटेशन के साथ चिह्नित किया गया है, हम ReflectionUtils.doWithFields कहते हैं, जो उन क्षेत्रों को सेट करेगा जिन्हें हमें और अधिक सुरुचिपूर्ण तरीके से ज़रूरत है। हम यह सुनिश्चित करते हैं कि फ़ील्ड मौजूद है, उसका नाम प्राप्त करें और जांचें कि यह नाम वह है जिसकी हमें आवश्यकता है।

 assert field != null; String fieldName = field.getName(); if (!fieldName.equals("entityClass") && !fieldName.equals("dtoClass")) { return; }

हम फ़ील्ड उपलब्ध कराते हैं (यह निजी है)

 ReflectionUtils.makeAccessible(field);

हम फ़ील्ड में मान सेट करते हैं।

 Class<?> targetClass = fieldName.equals("entityClass") ? mapper.entity() : mapper.dto(); field.set(bean, targetClass);

यह पहले से ही पर्याप्त है, लेकिन हम भविष्य के कोड को मैपर मापदंडों (वैकल्पिक) में गलत इकाई या डीटीओ को इंगित करके इसे तोड़ने के प्रयासों से सुरक्षित कर सकते हैं। हम जांचते हैं कि हम जिस वर्ग में क्षेत्र में स्थापित होने जा रहे हैं वह वास्तव में इसके लिए उपयुक्त है।

 Class<?> expectedClass = Stream.of(ResolvableType.forField(field).getGenerics()).findFirst() .orElseThrow(() -> new IllegalArgumentException("Unable to get generic type for " + fieldName)).resolve(); if (expectedClass != null && !expectedClass.isAssignableFrom(targetClass)) { throw new IllegalArgumentException(String.format("Unable to assign Class %s to expected Class: %s", targetClass, expectedClass)); }

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

Github पर परियोजना यहाँ है: promoscow@annotations.git

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

स्प्रिंग एनोटेशन: एओपी मैजिक

फ़ील्ड इनिशियलाइज़ेशन।

More articles: