ASP.NET MVC: रूपांतरण या इंजेक्शन? यही सवाल है

कक्षाओं में केवल सार पर निर्भरता होनी चाहिए, और ठोस नहीं, कक्षाएं। इस समस्या को हल करने के लिए, आप 2 सेवा लोकेटर और निर्भरता इंजेक्शन प्रथाओं के बीच चयन कर सकते हैं। ASP.NET MVC "डिपेंडेंसी रिज़ॉल्वर" का उपयोग करता है, जो सेवा लोकेटर हैं। ASP.NET MVC अनुप्रयोगों को विकसित करते समय, आपको यह निर्धारित करना चाहिए कि क्या समाधान या इंजेक्शन का उपयोग करना है, इसलिए पेशेवरों और विपक्ष क्या हैं?

मैं समझता हूं कि निर्भरता समस्या को हल करने के लिए डिपेंडेंसी इंजेक्शन बहुत मूल्यवान है, लेकिन मुझे विश्वास नहीं है कि यह एकमात्र सच है। निर्भरता इंजेक्शन केवल कार्यान्वयन का एक विस्तार है, जो वास्तव में मायने रखता है वह सिद्धांत है जो इसे अंतर्निहित करता है - निर्भरता का निर्भरता उलटा सिद्धांत। यदि आप एसओएलआईडी से परिचित हैं, तो निर्भरता में प्रतिलोमता व्युत्क्रम का सिद्धांत बस "डी" है। वैसे, प्रारंभिक से ठोस परिणाम पांच डिजाइन सिद्धांत हैं जिन्हें ऑब्जेक्ट-उन्मुख सॉफ़्टवेयर विकास में आवश्यक माना जाता है। ये पाँच सिद्धांत हैं:

• एकमात्र जिम्मेदारी का सिद्धांत
• खुलेपन / निकटता का सिद्धांत
• बारबरा लिस्कोव प्रतिस्थापन सिद्धांत
• इंटरफ़ेस जुदाई सिद्धांत
• निर्भरता उलटा सिद्धांत

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

निर्भरता उलटा सिद्धांत

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

public class MyComponent { public MyComponent() { : } public void DoSomeWork() { var logger = new Logger(); : } } 

जाहिर है, MyComponent वर्ग के पास लकड़हारा वर्ग पर निर्भरता है। यदि हम इसे ILogger में बदलने का निर्णय लेते हैं, तो हम इंटरफ़ेस को लागू करने वाले वास्तविक वर्ग का संदर्भ कैसे प्राप्त कर सकते हैं?

 public class MyComponent { public MyComponent() { : } public void DoSomeWork() { ILogger logger = ...; // who's going to provide this? : } } 

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

 public class MyComponent { public MyComponent() { : } public void DoSomeWork() { ILogger logger = ServiceLocator.GetService(); : } } 

आपके पास एक निर्भरता रिज़ॉल्यूशन घटक है जो आमतौर पर एक प्रकार (आमतौर पर एक इंटरफ़ेस) लेता है और एक विशिष्ट प्रकार का एक उदाहरण देता है जो इस इंटरफ़ेस को लागू करता है। प्रकार मिलान जो पास किया गया है और उदाहरण-विशिष्ट प्रकार लोकेटर घटक के कार्यान्वयन में छिपा हुआ है। इस मॉडल को सेवा लोकेटर पैटर्न के रूप में जाना जाता है।
यहाँ एक और दृष्टिकोण है:

 public class MyComponent { private ILogger _logger; public MyComponent(ILogger logger) { _logger = logger; } public void DoSomeWork() { // Use the logger component here _logger.Log(); : } } 

इस मामले में, MyComponent वर्ग को बाहरी दुनिया के साथ उपयोग के लिए ILogger घटक मिलता है। आपका वातावरण MyComponent पर भेजने से पहले रजिस्ट्रार को इनिशियलाइज़ करने का ध्यान रखेगा। यह निर्भरता इंजेक्शन मॉडल का सार है।
निर्भरता इंजेक्शन और सेवा लोकेटर के बीच अंतर (यदि कोई हो) क्या है? दोनों मॉडल निर्भरता व्युत्क्रम सिद्धांत को लागू करने में अच्छे हैं। सेवा लोकेटर मॉडल मौजूदा कोड में उपयोग करने के लिए आसान है, यह सार्वजनिक इंटरफ़ेस में परिवर्तन के लिए मजबूर किए बिना, समग्र डिजाइन को कमजोर बनाता है। इसी कारण से, सेवा लोकेटर मॉडल पर आधारित कोड डिपेंडेंसी इंजेक्शन पर आधारित समकक्ष कोड की तुलना में पढ़ने के लिए बदतर है।
निर्भरता इंजेक्शन स्पष्ट रूप से दिखाता है कि कक्षा में (या विधि) इंजेक्शन लगाने से पहले और बाद में किस प्रकार का होगा। इस कारण से, कोड क्लीनर और अधिक पठनीय हो जाता है। ASP.NET MVC के बारे में क्या?

ASP.NET MVC में निर्भरता इंजेक्शन

ASP.NET MVC कई विस्तार बिंदुओं के लिए डिज़ाइन किया गया है, लेकिन कुल मिलाकर यह निर्भरता इंजेक्शन के लिए व्यापक समर्थन प्रदान नहीं कर रहा है। सेवा लोकेटर शायद सबसे प्रभावी तरीका है ताकि मौजूदा प्रणाली को नए विस्तार बिंदुओं के साथ अधिक शिथिल रूप से जोड़ा जा सके, क्योंकि यह कम से कम घुसपैठ समाधान है। सेवा लोकेटर एक ब्लैक बॉक्स की तरह काम करता है जिसे आप एक निश्चित बिंदु पर सेट करते हैं और इसे नियम देते हैं, क्या अनुबंध आवश्यक हैं, और उन्हें कैसे प्राप्त करें। ASP.NET MVC में कई विस्तार बिंदु हैं जो सिस्टम के घटक हैं, लेकिन जिन्हें कस्टम लोगों के साथ भी बदला जा सकता है। तालिका ASP.NET MVC 3 पर ज्ञात विस्तार बिंदुओं को सूचीबद्ध करती है।

प्रदाता	विवरण
कार्रवाई करने वाला	// नियंत्रक वर्ग नियंत्रक के निर्माण में। InInInvoker = new YourActionInvoker ();
नियंत्रक कारखाना	// Global.asax में, Application_Start var factory = new YourControllerFactory (); नियंत्रकबेल्ट.क्रांति.सिटकंट्रोलरफैक्टरी (कारखाना);
शब्दकोश मूल्यों	// Global.asax में, Application_Start var providerFactory = नया YourValueProviderFactory (); ValueProviderFactories.Factories.Add (प्रदाताFactory);
मॉडल बांधने की मशीन	// Global.asax में, Application_Start ModelBinders.Binders.Add (टाइपऑफ़ (YourType), नया YourTypeBinder ());
मॉडल बाइंडर प्रदाता	// Global.asax में, Application_Start var प्रदाता = नया YourModelBinderProvider (); ModelBinderProviders.BinderProviders.Add (प्रदाता);
मॉडल मेटाडेटा	// Global.asax में, Application_Start ModelMetadataProviders.Current = new YourModelMetadataProvider ();
मॉडल सत्यापनकर्ता	// Global.asax में, Application_Start var validator = new YourModelValidatorProvider (); ModelValidatorProviders.Providers.Add (सत्यापनकर्ता);
TempData	// कंट्रोलर क्लास के कंस्ट्रक्टर में कंट्रोलर। टेम्पडाटाप्रोवाइडर = न्यू योरटेम्पडपाप्रोइडर ();
इंजन देखें	// Global.asax में, Application_Start ViewEngines.Engines.Clear (); ViewEngines.Engines.Add (नया YourViewEngine ());

इंजन देखें // Global.asax में, Application_Start ViewEngines.Engines.Clear (); ViewEngines.Engines.Add (नया YourViewEngine ());
ASP.NET MVC 3 से पहले, कस्टम घटकों को पंजीकृत करने का कोई मानक तरीका नहीं था। तालिका 1 में सूचीबद्ध प्रत्येक घटक को उपयोगकर्ता अनुप्रयोगों में एकीकरण के लिए अपने स्वयं के एपीआई की आवश्यकता होती है। संस्करण 3 से शुरू होकर, ASP.NET MVC आर्बिटर निर्भरता के आधार पर नए (वैकल्पिक) मॉडल पेश करता है। सिस्टम घटकों को बदलने के लिए, आप तालिका 1 में वर्णित पथ का अनुसरण कर सकते हैं या इस प्रकार के लिए एक इंजेक्शन (निर्भरता इंजेक्शन) पंजीकृत कर सकते हैं। ASP.NET रनटाइम निर्भरता का पता लगाएगा और आवश्यक होने पर संदर्भित करेगा।
निर्भरता संकल्प ASP.NET MVC कोड के साथ एकीकृत एक लोकेटर सेवा है। आर्बिट्रेटर मौजूदा (बड़े) कोड में निर्भरता उलटा सिद्धांत के कार्यान्वयन को जोड़ने का एक तरीका है। कोड के आकार और जटिलता के लिए, निर्भरता का उपयोग करना कम उपयुक्त है क्योंकि इसके लिए राज्य एपीआई में विभिन्न स्तरों पर बदलाव की आवश्यकता होगी। यह केवल ASP.NET MVC जैसी मूल बातें का विकल्प नहीं है। आइए ASP.NET MVC में मध्यस्थ निर्भरता के कार्यान्वयन के बारे में अधिक जानें।

अपनी निर्भरता रिज़ॉल्वर को परिभाषित करना

ASP.NET MVC डिपेंडेंसी रिज़ॉल्वर एक ऑब्जेक्ट है जो निम्न इंटरफ़ेस को लागू करता है

 { Object GetService(Type serviceType); IEnumerable<Object> GetServices(Type serviceType); } 

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

 public class SampleDependencyResolver : IDependencyResolver { public object GetService(Type serviceType) { if (serviceType == typeof(ISomeClass)) return new SomeClass(); : } public IEnumerable<object> GetServices(Type serviceType) { return Enumerable.Empty<Object>(); } } 

निम्न कोड दिखाता है कि निर्भरता को हल करने के लिए कनवर्टर यूनिटी (और फ़ाइल कॉन्फ़िगरेशन में इसका अनुभाग) का उपयोग कैसे करता है।

 public class UnityDependencyResolver : IDependencyResolver { private readonly IUnityContainer _container; public UnityDependencyResolver() : this(new UnityContainer().LoadConfiguration()) { } public UnityDependencyResolver(IUnityContainer container) { _container = container; } public Object GetService(Type serviceType) { return _container.Resolve(serviceType); } public IEnumerable<Object> GetServices(Type serviceType) { return _container.ResolveAll(serviceType); } } 

आप एक ASP.NET MVC संरचना के साथ अपनी अनुमतियाँ दर्ज करें DependencyResolver वर्ग और SetResolver विधि का उपयोग कर

 protected void Application_Start() { // Prepare and configure the IoC container var container = new UnityContainer(); : // Create and register the resolver var resolver = new UnityDependencyResolver(container); DependencyResolver.SetResolver(resolver); } 

यदि आप अनुमति से IoC ढांचे का उपयोग करते हैं, तो आपको इसे पंजीकृत प्रकारों की सूची प्रदान करने का सबसे अच्छा तरीका खोजने की आवश्यकता है। यदि आप नि: शुल्क कोड के माध्यम से इस जानकारी को पास करना पसंद करते हैं, तो आपको नाम बनाने से पहले आईओसी कंटेनर को पूरी तरह से कॉन्फ़िगर करने की आवश्यकता है। यदि आप एकता के नियमों के अनुसार, web.config फ़ाइल का उपयोग करके IoC को कॉन्फ़िगर करना चाहते हैं, तो आप अनुमति के लिए डिफ़ॉल्ट कंस्ट्रक्टर का उपयोग कर सकते हैं, जिसके लिए लोडिंग कॉन्फ़िगरेशन डेटा की आवश्यकता होती है। हालांकि, मैं ध्यान देता हूं कि यदि आपको IoC के किसी अलग ढांचे को लक्षित कर रहे हैं तो आपको इस कोड को संशोधित करने की आवश्यकता हो सकती है।
सामान्य तौर पर, रिज़ॉल्यूशन निर्भरता एक आंतरिक उपकरण है जिसे डेवलपर्स सिस्टम घटकों के बजाय अपने स्वयं के व्यक्तिगत घटकों को तैनात करने के लिए उपयोग कर सकते हैं। निर्भरता कनवर्टर की सुंदरता ASP.NET MVC का उपयोग करने के लिए सीमित है। समझने योग्य लक्ष्यों को प्राप्त करने के लिए कन्वर्टर्स को ज्ञात स्थानों पर बुलाया जाता है। दूसरे शब्दों में, यदि ASP.NET MVC एक कैश कंट्रोलर बनाने से पहले रूपांतरण का कारण नहीं बनता है, तो हम अपने साथ निर्मित कैश को बदलने के लिए दुर्भाग्य से ऐसा नहीं कर सकते हैं।

अनुप्रयोगों में परिवर्तनों का उपयोग करना

यह पता चला कि निर्भरता रूपांतरण नाम से ज्यादा कुछ नहीं है जो ASP.NET MVC सेवा की खोज के लिए उपयोग करता है। लेकिन आप वास्तविक अनुप्रयोगों में वैसे भी इसका उपयोग कैसे कर सकते हैं? इसका उत्तर बहुत सरल है, आपके पास केवल एक कनवर्टर होना चाहिए जिसमें आपको अपना सारा कॉस्टोमाइजेशन करना चाहिए, जैसे आप चाहते हैं। यहां निर्भरता रूपांतरण के लिए थोड़ा और विकल्प है, जिसका एक उदाहरण थोड़ा अधिक था।

 public class SampleDependencyResolver : IDependencyResolver { public object GetService(Type serviceType) { try { return serviceType == typeof(ModelMetadataProvider) ? new ExtendedAnnotationsMetadataProvider() : Activator.CreateInstance(serviceType); } catch { return null; } } public IEnumerable<object> GetServices(Type serviceType) { return Enumerable.Empty<object>(); } } 

GetService विधि प्रकार प्राप्त करती है, और इसे ज्ञात प्रकारों की सूची के साथ जांचती है। कुछ प्रसिद्ध इंटरफ़ेस प्रकारों के लिए, यह एक ज्ञात प्रकार का मैन्युअल रूप से बनाया गया उदाहरण वापस कर सकता है। अन्य प्रकारों के लिए, यह कुछ भी नहीं लौटा सकता है, इसका मतलब है कि मध्यस्थ इस प्रकार के साथ काम करने में सक्षम नहीं है।
ASP.NET MVC में निर्भरता मैपर अनुप्रयोग जीवन चक्र के दौरान किसी भी तरह से एक ही प्रकार को परिवर्तित नहीं कर सकता है। यद्यपि यह सामान्य लोकेटर सेवा के कार्यान्वयन में एक महत्वपूर्ण सीमा हो सकती है, यह विशिष्ट ASP.NET MVC संदर्भ में एक बड़ी समस्या नहीं है। निर्भरता रूपांतरण ASP.NET MVC की एक आंतरिक विशेषता है, और केवल ASP.NET MVC पंजीकृत कन्वर्टर्स को कॉल और उपयोग कब और कैसे करना है, यह तय करता है। अंततः, आपके कनवर्टर को केवल सीमित संख्या में कॉल किया जाएगा, और इंटरफ़ेस समझ से अधिक हो जाएगा।

तो क्या परिवर्तन या इंजेक्शन का उपयोग करें?

यदि आप डिजाइन दक्षता के संदर्भ में इस मुद्दे को देखते हैं, तो निर्भरता इंजेक्शन को प्राथमिकता दी जाती है क्योंकि यह डिजाइन को जिम्मेदारियों के एक साफ और क्रिस्टल स्पष्ट वितरण की ओर ले जाता है। निर्भरता इंजेक्शन का उपयोग करने के लिए, आपको अपना एपीआई बदलने की स्वतंत्रता लेनी होगी। यह संदर्भ के आधार पर स्वीकार्य नहीं हो सकता है, यह स्वीकार्य नहीं होगा, उदाहरण के लिए, जब ASP.NET MVC 2 से ASP.NET MVC 3 पर स्विच किया जा रहा है। इस कारण से, Microsoft ने निर्भरता कन्वर्टर्स का उपयोग करने का विकल्प चुना, क्लासिक के लिए एक फैंसी नाम सेवा लोकेटर घटक एक अधिक यथार्थवादी उदाहरण, लोकेटर सेवा एकमात्र विकल्प है जब आपको किसी बड़े मौजूदा एप्लिकेशन में रिफ्लेक्टर की आवश्यकता होती है

ps यह समझने के लिए मेरा पहला अनुवाद है।