jersey
जर्सी के साथ निर्भरता इंजेक्शन
खोज…
जर्सी के एचके 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);
}
बस। ये सिर्फ मूल बातें हैं। एचके और जर्सी करने के लिए बहुत अधिक चीजें हैं।