जावा ईई 6 में निर्भरता इंजेक्शन

JSR-299 के भीतर "जावा ईई प्लेटफॉर्म के लिए कॉन्टेक्ट्स एंड डिपेंडेंसी इंजेक्शन" (पूर्व में वेबबीन), एक विनिर्देश विकसित किया गया था जो जावा ईई में शामिल निर्भरता इंजेक्शन पैटर्न के कार्यान्वयन का वर्णन करता है। संदर्भ कार्यान्वयन वेल्ड फ्रेमवर्क है, जिस पर इस लेख में चर्चा की जाएगी ।

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

लेख में मैं वेल्ड के मुख्य फायदे और नुकसान के बारे में बात करना चाहूंगा।

सिद्धांत की बिट

शुरुआत में, यह JSR-330 "जावा के लिए निर्भरता इंजेक्शन" विनिर्देशन का उल्लेख करने योग्य है, जो स्प्रिंगसोर्स और Google के इंजीनियरों द्वारा विकसित किया गया है, जो जावा अनुप्रयोगों में DI को लागू करने के लिए बुनियादी तंत्र को परिभाषित करता है। स्प्रिंग और गाइस की तरह, वेल्ड इस विनिर्देश द्वारा प्रदान किए गए एनोटेशन का उपयोग करता है।

वेल्ड न केवल जावा ईई अनुप्रयोगों के साथ, बल्कि सामान्य जावा एसई वातावरण के साथ भी काम कर सकता है। स्वाभाविक रूप से टॉमकैट, जेट्टी के लिए समर्थन है; आधिकारिक दस्तावेज विस्तृत सेटअप निर्देशों का वर्णन करता है।

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

CDI को सक्षम करने के लिए, आपको वेब एप्लिकेशन (या जावा SE के लिए META-INF) के लिए WEB-INF निर्देशिका में एक बीन्स.xml फ़ाइल बनाने की आवश्यकता है:

<बीन्स xmlns = " java.sun.com/xml/ns/javaee "
xmlns: xsi = " www.w3.org/2001/XMLSchema-instance "
xsi: schemaLocation = " java.sun.com/xml/ns/javaee java.sun.com/xml/ns/javaee/beans_1_0.xsd ">

</ बीन्स>

वसंत की तरह, सीडीआई के संदर्भ में सेम की अपनी स्कोप हैं, जिसके दौरान वे मौजूद हैं। गुंजाइश javax.enterprise.context पैकेज से एनोटेशन का उपयोग करके सेट की गई है:

• @RequestScoped
• @SessionScoped
• @ApplicationScoped
• आश्रित
• @ConversationScoped

पहले तीन स्कोप के साथ, सब कुछ स्पष्ट है। CDI में डिफ़ॉल्ट रूप से उपयोग किया जाता है, डिपेंडेंट क्लाइंट बीन से सीधे जुड़ा होता है और हर समय मौजूद रहता है जबकि "पैरेंट" रहता है।

@ConversationScoped किसी ब्राउज़र में किसी विशिष्ट टैब के साथ सहभागिता करने के लिए उपयोगकर्ता की निश्चित अवधि का प्रतिनिधित्व करता है। इसलिए, यह कुछ हद तक एक सत्र के जीवन चक्र के समान है, लेकिन महत्वपूर्ण अंतर यह है कि "सत्र" की शुरुआत मैन्युअल रूप से सेट की जाती है। ऐसा करने के लिए, javax.enterprise.context.Conversation इंटरफ़ेस घोषित किया जाता है, जो एक समय बीतने के बाद सत्र को बंद करने के लिए स्टार्ट (), एंड () विधियों, साथ ही सेटटाइम (लंबी) को परिभाषित करता है।

बेशक, वहाँ सिंगलटन है , जो javax.inject पैकेज में स्थित है, क्योंकि JSR-330 विनिर्देश का हिस्सा है। इस दायरे के सीडीआई कार्यान्वयन में, एक विशेषता है: इंजेक्शन प्रक्रिया के दौरान, ग्राहक को कंटेनर द्वारा बनाई गई वास्तविक वस्तु का लिंक प्राप्त होता है, न कि प्रॉक्सी को। नतीजतन, अगर एक सिंगलटन की स्थिति बदल जाती है, और इसका उपयोग करने वाले सेम, उदाहरण के लिए, या धारावाहिक रूप से परिवर्तित हो जाएंगे तो डेटा अस्पष्टता की समस्या हो सकती है।

अपना दायरा बनाने के लिए, आपको एक एनोटेशन लिखना होगा और इसे @ScopeType के साथ चिह्नित करना होगा, साथ ही javax.enterprise.context.spi.Context इंटरफ़ेस को लागू करना होगा।

इस तथ्य के साथ थोड़ा भ्रम पैदा हो सकता है कि javax.faces.bean पैकेज में स्कैन किए गए JSF सेम प्रबंधित करने के लिए एनोटेशन शामिल हैं। यह इस तथ्य के कारण है कि जेएसएफ अनुप्रयोगों में सीडीआई का उपयोग आवश्यक नहीं है: वास्तव में, आप @EJB, @PersistenceContext, आदि का उपयोग करके मानक इंजेक्शन के साथ प्राप्त कर सकते हैं। हालांकि, अगर हम DI से उन्नत टुकड़ों का उपयोग करना चाहते हैं, तो JSR-299 और 330 से एनोटेशन का उपयोग करना अधिक सुविधाजनक है।

primerchik

मान लीजिए कि एक सेवा है जो उपयोगकर्ता के उपयोगकर्ता नाम और पासवर्ड की जांच करती है।

public interface ILoginService extends Serializable { boolean login(String name, String password); } 

आइए इसका कार्यान्वयन लिखें:

 public class LoginService implements ILoginService { @Override public boolean login(String name, String password) { return "bugs".equalsIgnoreCase(name) && "bunny".equalsIgnoreCase(password); } } 

अब एक नियंत्रक जोड़ें जो लॉगिन सेवा का उपयोग करेगा:

 @Named @RequestScoped public class LoginController { @Inject private ILoginService loginService; private String login; private String password; public String doLogin() { return loginService.login(login, password) ? "main.xhtml" : "failed.xhtml"; } // getters and setters will be omitted... } 

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

विकास प्रक्रिया में, हम अपनी स्वयं की सेवा को लागू करना चाहते हैं, निम्न सामग्री में से लगभग:

 public class StubLoginService implements ILoginService { @Override public boolean login(String name, String password) { return true; } } 

अब, आवेदन को फिर से तैनात करने के बाद, कंसोल में एक त्रुटि दिखाई देगी:

 WELD-001409 Ambiguous dependencies for type [ILoginService] with qualifiers [@Default] at injection point [[field] @Inject private com.sample.controller.LoginController.loginService]. 

यदि इंजेक्शन के बिंदु पर कई कार्यान्वयन उपयुक्त हैं, तो वेल्ड एक अपवाद फेंकता है। सीडीआई डेवलपर्स ने इस समस्या का समाधान प्रदान किया है। ऐसा करने के लिए, StubLoginService को वैकल्पिक एनोटेशन के साथ चिह्नित करें:

 @Alternative public class StubLoginService implements ILoginService { … } 

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

<वैकल्पिक>
<class> com.sample.service.StubLoginService </ class>
</ वैकल्पिक>

इस प्रकार, हमने एप्लिकेशन स्टार्टअप पर कार्यान्वयन को बदल दिया। काम करने वाले संस्करण को वापस करने के लिए, बिन सेटिंग्स फ़ाइल में लाइन पर टिप्पणी करना पर्याप्त है।

जैसा कि आमतौर पर होता है, विनिर्देश अद्यतन किया गया था और अब सेवा को एमडी 5 एल्गोरिथ्म का उपयोग करके हैश द्वारा पासवर्ड की जांच करनी चाहिए। एक और कार्यान्वयन जोड़ें:

 public class Md5LoginService implements ILoginService { @Override public boolean login(String name, String password) { //  ... } } 

अब हमें वेल्ड को यह बताने की आवश्यकता है कि यह Md5LoginService है जिसे इंजेक्शन बिंदु पर प्रतिस्थापित करने की आवश्यकता है। हम इसके लिए क्वालिफायर एनोटेशन का उपयोग करेंगे। यह विचार अपने आप में बहुत सरल है: जब कंटेनर निर्णय लेता है कि किस कार्यान्वयन को लागू करना है, तो यह इंजेक्शन बिंदु पर एनोटेशन और संभावित कार्यान्वयन के एनोटेशन की जांच करता है। चेक किए गए एनोटेशन को क्वालिफायर कहा जाता है। विनिर्देशक एक नियमित जावा एनोटेशन है, जो अतिरिक्त रूप से javax .inject.Qualifier द्वारा एनोटेट किया जाता है:

 @Retention(RetentionPolicy.RUNTIME) @Target({FIELD, PARAMETER, TYPE, METHOD}) @Qualifier public @interface Hash { } 

अब, नियंत्रक में, आइए उस क्षेत्र को रद्द करें जिसमें प्रतिस्थापन किया जाएगा, साथ ही Md5LoginService के कार्यान्वयन:

 @Hash public class Md5LoginService implements ILoginService { } @Named @RequestScoped public class LoginController { @Inject @Hash private ILoginService loginService; } 

अब वेल्ड वांछित कार्यान्वयन का स्थान लेगा। बेशक, सवाल उठता है: हर बार एक नया एनोटेशन लिखें?! ज्यादातर मामलों में, आपको ऐसा करना होगा, लेकिन यह शुल्क टाइपसफे के लिए है। इसके अलावा, एनोटेशन को इस तरह से उदाहरण के लिए एकत्र किया जा सकता है:

 @Hash @Fast public class Md5LoginService implements ILoginService { } @Named @RequestScoped public class LoginController { @Inject @Hash @Fast private ILoginService loginService; } 

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

 @Retention(RetentionPolicy.RUNTIME) @Target({FIELD, PARAMETER, TYPE, METHOD}) @Qualifier public @interface Hash { HashType value() default HashType.SHA; //    @Nonbinding       @Nonbinding String desc() default ""; } @Hash(HashType.MD5) public class Md5LoginService implements ILoginService { } @Named @RequestScoped public class LoginController { @Inject @Hash(HashType.MD5) private ILoginService loginService; } 

यानी प्रश्न में उदाहरण के लिए, हमने एक नए प्रकार को एक एन्यूमरेशन प्रकार के साथ जोड़ा है जो दर्शाता है कि यह किस हैश एल्गोरिथम है। यद्यपि एक नया एनोटेशन और एन्यूमरेशन लिखना आवश्यक था, लेकिन अब वांछित कार्यान्वयन के विकल्प के साथ गलती करना लगभग असंभव है, और कोड की पठनीयता भी बढ़ गई है। इसके अलावा, आपको यह हमेशा याद रखना चाहिए कि यदि कार्यान्वयन में योग्यता नहीं है, तो इसे डिफ़ॉल्ट javax .enterprise.inject.Default द्वारा जोड़ा जाता है।

सच है, किए गए जोड़तोड़ के बाद, स्टुब्लॉगिन सर्विस ने क्षेत्र में प्रतिस्थापन करना बंद कर दिया। यह इस तथ्य के कारण है कि इसमें हैश स्पेसियर नहीं है, इसलिए वेल्ड इसे इंटरफ़ेस के संभावित कार्यान्वयन के रूप में भी नहीं मानता है। इस समस्या को हल करने के लिए एक चाल है: @Specializes एनोटेशन, जो दूसरे सेम के कार्यान्वयन की जगह लेता है। वेल्ड को बताने के लिए कि किस विशेष कार्यान्वयन को प्रतिस्थापित करना है, आपको बस इसे विस्तारित करने की आवश्यकता है:

 @Alternative @Specializes public class StubLoginService extends Md5LoginService { @Override public boolean login(String name, String password) { return true; } } 

कल्पना करें कि हमारे पास नई आवश्यकताएं हैं: उपयोगकर्ता को सिस्टम में प्रवेश करने का प्रयास करते समय, आपको सिस्टम में लागू सभी संभावित एल्गोरिदम के साथ पासवर्ड को सत्यापित करने का प्रयास करने की आवश्यकता है। यानी हमें इंटरफ़ेस के सभी कार्यान्वयन पर पुनरावृति करने की आवश्यकता है। वसंत में, इस समस्या को वांछित इंटरफ़ेस द्वारा सामान्यीकृत संग्रह में प्रतिस्थापित करके हल किया जाता है। वेल्ड में, आप javax.enterprise.inject.Instance <?> इंटरफ़ेस और इसके लिए कोई भी अंतर्निहित विनिर्देशक का उपयोग कर सकते हैं। अभी के लिए, वैकल्पिक कार्यान्वयन अक्षम करें और देखें कि क्या होता है:

 @Named @RequestScoped public class LoginController { @Inject @Any private Instance<ILoginService> loginService; private String login; private String password; public String doLogin() { for (ILoginService service : loginService) { if (service.login(login, password)) return "main.xhtml"; } return "failed.xhtml"; } } 

किसी भी एनोटेशन से पता चलता है कि हमें इस बात की परवाह नहीं है कि क्रियान्वयन में किस तरह के क्वालिफायर हो सकते हैं। इंस्टेंस इंटरफ़ेस Iterable को लागू करता है, इसलिए आप इस तरह के सुंदर काम फोरचेक के माध्यम से कर सकते हैं। सामान्य तौर पर, यह इंटरफ़ेस न केवल इसके लिए अभिप्रेत है। इसमें एक अतिभारित चयन () विधि है, जो रनटाइम को वांछित कार्यान्वयन का चयन करने की अनुमति देता है। मापदंडों के रूप में, यह एनोटेशन के उदाहरण लेता है। सामान्य तौर पर, यह अब कुछ हद तक "असामान्य" है, क्योंकि आपको अनाम कक्षाएं बनाना होगा (या अलग से बनाना होगा, बस एक ही स्थान पर उपयोग करना होगा)। यह आंशिक रूप से सार वर्ग AnnotationLiteral <?> से हल किया गया है जिससे आप वांछित एनोटेशन के अनुसार विस्तार और सामान्यीकरण कर सकते हैं। इसके अलावा, इंस्टेंस के पास विशेष तरीके हैं जो कि असंतुष्ट और isAigiguous है, जिसके साथ आप रनटाइम में जांच कर सकते हैं कि क्या कोई उपयुक्त कार्यान्वयन है और उसके बाद गेट () विधि के माध्यम से उसका उदाहरण प्राप्त करें। यह कुछ इस तरह दिखता है:

 @Inject @Any Instance<ILoginService> loginServiceInstance; public String doLogin() { Instance<ILoginService> tempInstance = isUltimateVersion ? loginServiceInstance.select(new AnnotationLiteral<Hash>(){}) : loginServiceInstance.select(new AnnotationLiteral<Default>(){}); if (tempInstance.isAmbiguous() || tempInstance.isUnsatisfied()) { throw new IllegalStateException("    "); } return tempInstance.get().login(login, password) ? "main.xhtml" : "failed.xhtml"; } 

यह स्पष्ट है कि इस मामले में loginServiceInstance के माध्यम से एक लूप के माध्यम से जाना संभव था, जैसा कि ऊपर दिए गए उदाहरण में किया गया था, और getClass का उपयोग करके वांछित कार्यान्वयन ढूंढें ()। बराबर (), लेकिन फिर कार्यान्वयन बदलते समय, मुझे इस स्थान में कोड को भी संपादित करना था। वेल्ड एक अधिक लचीला और सुरक्षित दृष्टिकोण का परिचय देता है, हालांकि इसमें नए अमूर्त का थोड़ा सा पता लगाना शामिल है।

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

यह सब अच्छी तरह से और अच्छा है, लेकिन क्या करना है जब हमें किसी मुश्किल तरीके से एक कक्षा को तत्काल करने की आवश्यकता है? फिर से, xml संदर्भ में स्प्रिंग, वस्तुओं के गुणों को सूचीबद्ध करने, सूची बनाने, नक्शे, आदि के लिए टैग का एक समृद्ध सेट प्रदान करता है। वेल्ड के पास इसके लिए केवल एक एनोटेशन @Produces है, जो उन तरीकों और क्षेत्रों को चिह्नित करता है जो ऑब्जेक्ट उत्पन्न करते हैं (स्केलर प्रकार सहित)। हम अपने पिछले उदाहरण को फिर से लिखते हैं:

 @ApplicationScoped public class LoginServiceFactory implements Serializable { // @Factory -   @Produces @Factory public ILoginService buildLoginService() { return isUltimateVersion ? new Md5LoginService() : new LoginService(); } } 

अब हम उस विशेषांक के माध्यम से इंगित करते हैं जहाँ हम कार्यान्वयन प्राप्त करना चाहते हैं:

  @Inject @Factory private ILoginService loginService; 

बस इतना ही। एक नियमित क्षेत्र भी एक स्रोत हो सकता है। प्रतिस्थापन नियम समान हैं। इसके अलावा, आप बिल्ड बिल्ड में भी इंजेक्शन लगा सकते हैं

  @Produces @Factory private ILoginService buildLoginService( @Hash(HashType.MD5) ILoginService md5LoginService, ILoginService defaultLoginService) { return isUltimateVersion ? md5LoginService : defaultLoginService; } 

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

 @Produces @Factory @SessionScoped private ILoginService buildLoginService( @Hash(HashType.MD5) ILoginService md5LoginService, ILoginService defaultLoginService) { return isUltimateVersion ? md5LoginService : defaultLoginService; } 

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

 private void dispose(@Disposes @Factory ILoginService service) { log.info("LoginService disposed"); } 

जब ऑब्जेक्ट का जीवन चक्र समाप्त हो जाता है, तो वेल्ड उन तरीकों की खोज करता है जो जनरेटर विधि के प्रकार और विनिर्देश से मेल खाते हैं, साथ ही @Disposed को टैग किया गया है और इसे कॉल करता है।

निष्कर्ष

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

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

सूत्रों का कहना है

JSR-299
आधिकारिक वेल्ड प्रलेखन
Oracle इंजीनियर द्वारा ग्रेट JSR-299 परिचयात्मक लेख
सीडीआई पर लेखों की एक श्रृंखला नेटबीन्स में रूसी ( 1 , 2 , 3 , 4 ) का समर्थन करती है