खोज…


जर्सी के एचके 2 का उपयोग करके बुनियादी निर्भरता इंजेक्शन

जर्सी (2) अपने निर्भरता इंजेक्शन (डीआई) प्रणाली के रूप में एचके 2 का उपयोग करती है। हम अन्य इंजेक्शन प्रणालियों का उपयोग कर सकते हैं, लेकिन इसका बुनियादी ढांचा HK2 के साथ बनाया गया है, और हमें अपने अनुप्रयोगों के भीतर भी इसका उपयोग करने की अनुमति देता है।

जर्सी के साथ सरल निर्भरता इंजेक्शन स्थापित करना कोड की कुछ पंक्तियाँ लेता है। उदाहरण के लिए कहें कि हमारे पास एक सेवा है जिसे हम अपने संसाधनों में इंजेक्ट करना चाहते हैं।

public class GreetingService {
    public String getGreeting(String name) {
        return "Hello " + name + "!";
    }
}

और हम इस सेवा को जर्सी संसाधन में इंजेक्ट करना चाहते हैं

@Path("greeting")
public class GreetingResource {

    @Inject
    public GreetingService greetingService;

    @GET
    public String get(@QueryParam("name") String name) {
        return this.greetingService.getGreeting(name);
    }
}

काम करने के लिए इंजेक्शन के लिए, हम सभी की जरूरत है एक सरल विन्यास है

@ApplicationPath("/api")
public class AppConfig extends ResourceConfig {
    public AppConfig() {
        register(GreetingResource.class);
        register(new AbstractBinder() {
            @Override
            protected void configure() {
                bindAsContract(GreetingService.class);
            }
        });
    }
}

यहां हम यह कह रहे हैं कि हम GreetingService को इंजेक्शन प्रणाली से बांधना चाहते हैं, और इसे उसी वर्ग द्वारा इंजेक्शन के रूप में विज्ञापित करते हैं। अंतिम कथन का अर्थ यह है कि हम इसे केवल GreetingService सर्विस के रूप में इंजेक्ट कर सकते हैं और (शायद स्पष्ट रूप से) किसी अन्य वर्ग द्वारा नहीं। जैसा कि आप बाद में देखेंगे, इसे बदलना संभव है।

बस। वह सब आपको चाहिए। यदि आप इस ResourceConfig कॉन्फ़िगरेशन (शायद आप web.xml का उपयोग कर रहे हैं) से परिचित नहीं हैं, तो SO SO डॉक्स पर जर्सी विषय में कॉन्फ़िगरेशन JAX-RS को देखें


नोट: ऊपर दिया गया इंजेक्शन फ़ील्ड इंजेक्शन है, जहाँ सेवा को संसाधन के क्षेत्र में इंजेक्ट किया जाता है। एक अन्य प्रकार का इंजेक्शन कंस्ट्रक्टर इंजेक्शन है, जहां सेवा को कंस्ट्रक्टर में इंजेक्ट किया जाता है

private final GreetingService greetingService;

@Inject   
public GreetingResource(GreetingService greetingService) {
     this.greetingService = greetingService;
}

यह संभवतः फ़ील्ड इंजेक्शन के विपरीत जाने का पसंदीदा तरीका है, क्योंकि यह इकाई परीक्षण के लिए संसाधन को आसान बनाता है। कंस्ट्रक्टर इंजेक्शन को किसी अलग कॉन्फ़िगरेशन की आवश्यकता नहीं होती है।


ठीक है अब यह कहते हैं कि एक वर्ग के बजाय, GreetingService एक इंटरफ़ेस है, और हमारे पास इसका कार्यान्वयन है (जो बहुत आम है)। उसे कॉन्फ़िगर करने के लिए, हम उपरोक्त configure विधि में निम्नलिखित सिंटैक्स का उपयोग करेंगे

@Override
protected void configure() {
    bind(NiceGreetingService.class).to(GreetingService.class);
}

यह " NiceGreetingService , और इसे GreetingService NiceGreetingService रूप में विज्ञापित करता है" के रूप में पढ़ता है। इसका मतलब है कि हम ऊपर दिए गए GreetingResource में ठीक उसी कोड का उपयोग कर सकते हैं, क्योंकि हम अनुबंध को GreetingService रूप में विज्ञापित करते हैं, न कि NiceGreetingService । लेकिन वास्तविक कार्यान्वयन, जब इंजेक्शन लगाया जाता है, तो यह NiceGreetingService

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

@Override
protected void configure() {
    bind(NiceGreetingService.class)
            .to(GreetingService.class)
            .in(RequestScoped.class);
}

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

उपलब्ध अन्य दो स्कोप्स Singleton (केवल एक उदाहरण बनाया गया) और Immediate ( Singleton तरह) हैं, लेकिन स्टार्टअप पर बनाया गया है (जबकि Singleton साथ, यह पहले अनुरोध तक नहीं बना है)।

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

@Override
protected void configure() {
    bind(new NiceGreetingService())
            .to(GreetingService.class);
}

क्या होगा अगर हमारे पास कुछ जटिल सृजन तर्क हैं या सेवा के लिए कुछ अनुरोध संदर्भ जानकारी की आवश्यकता है। इस मामले में Factory एस हैं। ज्यादातर चीजें हम अपने जर्सी संसाधनों में इंजेक्ट कर सकते हैं, हम एक Factory में भी इंजेक्ट कर सकते हैं। उदाहरण के लिए

public class GreetingServiceFactory implements Factory<GreetingService> {
    
    @Context
    UriInfo uriInfo;
    
    @Override
    public GreetingService provide() {
        return new GreetingService(
                uriInfo.getQueryParameters().getFirst("name"));
    }
    
    @Override
    public void dispose(GreetingService service) {
        /* noop */
    }
}

यहां हमारे पास एक कारखाना है, जो UriInfo से अनुरोध जानकारी प्राप्त करता है, इस मामले में एक क्वेरी पैरामीटर है, और हम इसे से GreetingService बनाते हैं। इसे कॉन्फ़िगर करने के लिए, हम निम्नलिखित सिंटैक्स का उपयोग करते हैं

@Override
protected void configure() {
    bindFactory(GreetingServiceFactory.class)
            .to(GreetingService.class)
            .in(RequestScoped.class);
}

बस। ये सिर्फ मूल बातें हैं। एचके और जर्सी करने के लिए बहुत अधिक चीजें हैं।



Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow