मान्य ASP.NET कोर

विशेष रूप से "24 घंटों में सी + +" श्रृंखला से पुस्तक प्रेमियों के लिए, मैंने ASP.NET कोर के बारे में एक लेख लिखने का फैसला किया।

यदि आपने .NET से पहले या किसी भी समान प्लेटफ़ॉर्म के तहत विकसित नहीं किया है, तो यह आपके लिए कटौती के तहत जाने का कोई मतलब नहीं है। लेकिन अगर आप यह जानने में रुचि रखते हैं कि IoC, DI, DIP, इन्ट्रिप्टर्स, मिडलवेयर, फिल्टर्स (यानी, सब कुछ जो कि क्लासिक .NET से अलग है), तो आपको निश्चित रूप से "Read more" पर क्लिक करना होगा, जैसा कि आप विकसित कर रहे हैं। यह सब समझे बिना, यह स्पष्ट रूप से सही नहीं है।

आईओसी, डीआई, डीआईपी

यदि एक थिएटर एक हैंगर से शुरू होता है, तो ASP.NET कोर एक डिपेंडेंसी इंजेक्शन के साथ शुरू होता है। DI से निपटने के लिए, आपको यह समझने की आवश्यकता है कि IoC क्या है।

IoC के बारे में बोलते हुए, एक अक्सर "हमें कॉल न करें, हम आपको कॉल करेंगे" के हॉलीवुड सिद्धांत को याद करते हैं। जिसका अर्थ है "हमें कॉल करने की आवश्यकता नहीं है, हम आपको खुद कॉल करेंगे।"

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

आइए एक उदाहरण के रूप में एक साधारण कंसोल एप्लिकेशन का उपयोग करके आईओसी को देखें।

मान लें कि हमारे पास दो सरल वर्ग हैं जो एक विधि के साथ एक इंटरफ़ेस लागू करते हैं:

class ConsoleLayer : ILayer { public void Write(string text) { Console.WriteLine(text); } } class DebugLayer : ILayer { public void Write(string text) { Debug.WriteLine(text); } } interface ILayer { void Write(string text); } 

वे दोनों अमूर्तता पर निर्भर करते हैं (इस मामले में, इंटरफ़ेस एक अमूर्त के रूप में कार्य करता है)।

और मान लें कि हमारे पास इन कक्षाओं का उपयोग करने वाली एक उच्च स्तरीय वस्तु है:

  class Logging : ILayer { private ILayer _instance; public Logging(int i) { if (i == 1) { _instance = new ConsoleLayer(); } else { _instance = new DebugLayer(); } } public void Write(string text) { _instance.Write(text); } } 

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

उच्च-स्तरीय वस्तुएँ निम्न-स्तरीय वस्तुओं से स्वतंत्र होती हैं। वे और वे दोनों सार पर निर्भर हैं।

हमारे मामले में, ILayer एक अमूर्त के रूप में कार्य करता है।

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

  static void Main(string[] args) { var log = new Logging(1); log.Write("Hello!"); Console.Read(); } 

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

  class Logging { private ILayer _instance; public Logging(ILayer instance) { _instance = instance; } public void Write(string text) { _instance.Write(text); } } 

और अब, हमारा मुख्य वर्ग इस तरह दिखेगा:

  static void Main(string[] args) { var log = new Logging(new DebugLayer()); log.Write("Hello!"); Console.Read(); } 

वास्तव में, हम अपने लॉगिंग ऑब्जेक्ट को हमारे लिए आवश्यक वस्तु से सजाते हैं।

अब हमारा आवेदन निर्भरता उलटा सिद्धांत के दूसरे भाग का अनुपालन करता है:

सार विवरण से स्वतंत्र हैं। विवरण सार पर निर्भर करते हैं। यानी हम लॉगिंग क्लास में क्या हो रहा है, इसका विवरण नहीं जानते हैं, हम सिर्फ उस क्लास को पास करते हैं जो आवश्यक अमूर्तता को लागू करता है।

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

अब हमने यह पता लगा लिया है कि नियंत्रण का व्युत्क्रम (IoC) क्या है और निर्भरता व्युत्क्रमण (DIP) क्या है। यह समझने के लिए बना हुआ है कि डिपेंडेंसी इंजेक्शन (DI) क्या है। IoC एक डिजाइन प्रतिमान है। डिपेंडेंसी इंजेक्शन एक पैटर्न है। लॉगिंग क्लास के कंस्ट्रक्टर में यही हो रहा है। हमें एक विशिष्ट निर्भरता का उदाहरण मिलता है। लॉगिंग वर्ग उस श्रेणी के उदाहरण पर निर्भर करता है जो ILayer को लागू करता है। और इस उदाहरण को कंस्ट्रक्टर के माध्यम से इंजेक्ट किया जाता है।

IoC कंटेनर

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

  public static class IoCContainer { private static readonly Dictionary<Type, Type> _registeredObjects = new Dictionary<Type, Type>(); public static dynamic Resolve<TKey>() { return Activator.CreateInstance(_registeredObjects[typeof(TKey)]); } public static void Register<TKey, TConcrete>() where TConcrete : TKey { _registeredObjects[typeof(TKey)] = typeof(TConcrete); } } 

कोड की केवल एक दर्जन लाइनें, लेकिन आप पहले से ही इसका उपयोग कर सकते हैं (उत्पादन के लिए नहीं, बेशक, लेकिन शैक्षिक उद्देश्यों के लिए)।

आप निर्भरता दर्ज कर सकते हैं (उदाहरण के लिए, ConsoleLayer या DebugLayer जो हमने पिछले उदाहरण में उपयोग की थी) इस तरह से:

  IoCContainer.Register<ILayer, ConsoleLayer>(); 

और कंटेनर से इसे प्रोग्राम के आवश्यक स्थान पर इस तरह से निकालें:

  ILayer layer = IoCContainer.Resolve<ILayer>(); layer.Write("Hello from IoC!"); 

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

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

संरचना रूट में सेवा जीवनकाल + विभिन्न विस्तार विधियाँ

ASP.NET कोर अनुप्रयोगों में Startup.cs फ़ाइल होती है, जो DI को कॉन्फ़िगर करने के लिए अनुप्रयोग का प्रारंभिक बिंदु है। कॉन्फ़िगर्सशिप विधि में DI को कॉन्फ़िगर करता है।

  public void ConfigureServices(IServiceCollection services) { services.AddScoped<ISomeRepository, SomeRepository>(); } 

यह कोड SomeRepository वर्ग को DI कंटेनर में जोड़ेगा, जो ISomeRepository इंटरफ़ेस को कार्यान्वित करता है। तथ्य यह है कि सेवा को AddScoped का उपयोग करके कंटेनर में जोड़ा जाता है, इसका मतलब है कि जब भी पृष्ठ का अनुरोध किया जाता है, तो कक्षा का एक उदाहरण बनाया जाएगा।
आप एक इंटरफ़ेस निर्दिष्ट किए बिना एक कंटेनर में एक सेवा जोड़ सकते हैं।

  services.AddScoped<SomeRepository>(); 

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

एक सेवा को जोड़ने के लिए 2 और विकल्प हैं - AddSingleton और AddTransient।
AddSingleton का उपयोग करते समय, सेवा एक बार बनाई जाती है, और एप्लिकेशन का उपयोग करते समय, कॉल उसी उदाहरण पर जाती है। इस विधि का विशेष रूप से सावधानी से उपयोग करें, क्योंकि मेमोरी लीक और मल्टीथ्रेडिंग समस्याएं संभव हैं।

AddSingleton में थोड़ी सुविधा है। इसे या तो इसकी पहली पहुंच में शुरू किया जा सकता है

  services.AddSingleton<IYourService, YourService>(); 

या तो तुरंत जब कंस्ट्रक्टर में जोड़ा जाता है

  services.AddSingleton<IYourService>(new YourService(param)); 

दूसरे तरीके में, आप कंस्ट्रक्टर में एक पैरामीटर भी जोड़ सकते हैं।
यदि आप AddSingleton का उपयोग करके न केवल जोड़े गए किसी सेवा के निर्माता के लिए एक पैरामीटर जोड़ना चाहते हैं, बल्कि AddTransient / AddScoped का उपयोग भी कर सकते हैं, तो आप लैम्ब्डा अभिव्यक्ति का उपयोग कर सकते हैं:

  services.AddTransient<IYourService>(o => new YourService(param)); 

और अंत में, AddTransient का उपयोग करते समय, जब आप इसे एक्सेस करते हैं तो हर बार एक सेवा बनाई जाती है। हल्के सेवाओं के लिए बढ़िया जो स्मृति और संसाधनों का उपभोग नहीं करते हैं।

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

  public class Operation { public Guid OperationId { get; private set; } public Operation() { OperationId = Guid.NewGuid(); } } 

और एक दूसरी श्रेणी है जिसमें एक आश्रित सेवा के रूप में पहला है और एक निर्माता पैरामीटर के रूप में इस निर्भरता को प्राप्त करता है:

  public class OperationService { public Operation Operation { get; } public OperationService (Operation operation) { Operation = operation; } } 

अब हम दो सेवाओं को इंजेक्ट करते हैं:

  services.AddTransient<Operation>(); services.AddScoped<OperationService>(); 

और कार्रवाई में कुछ नियंत्रक में, हमारी निर्भरता की रसीद जोड़ें और डिबग विंडो में मान प्रदर्शित करें।

  public IActionResult Index([FromServices] Operation operation, [FromServices] OperationService operationService) { Debug.WriteLine(operation.OperationId); Debug.WriteLine(operationService.Operation.OperationId); return View(); } 

तो, परिणामस्वरूप, हमें 2 अलग-अलग दिशानिर्देश मिलते हैं। लेकिन अगर हम AddTcient को AddScoped से बदल देते हैं, तो परिणामस्वरूप हमें 2 समान मान मिलते हैं।

ASP.NET कोर अनुप्रयोग IoC कंटेनर में डिफ़ॉल्ट रूप से कुछ सेवाएँ हैं। उदाहरण के लिए, IConfiguration एक ऐसी सेवा है जिसके साथ आप एप्लिकेशन appsettings.json और appsettings.Development.json से सेटिंग प्राप्त कर सकते हैं। IHostingEnvironment और ILoggerFactory जिसके साथ आप वर्तमान कॉन्फ़िगरेशन और एक सहायक वर्ग प्राप्त कर सकते हैं जो लॉगिंग की अनुमति देता है।

निम्न विशिष्ट निर्माण (सबसे सामान्य उदाहरण) का उपयोग करके कंटेनर से कक्षाएं पुनः प्राप्त की जाती हैं:

  private readonly IConfiguration _configuration; public SomePageController(IConfiguration configuration) { _configuration = configuration; } public async Task<IActionResult> Index() { string connectionString = _configuration["connectionString"]; } 

नियंत्रक के दायरे में निजी रीडायनली एक्सेस मॉडिफायर वाला एक चर बनाया जाता है। निर्भरता को क्लास के कंस्ट्रक्टर में कंटेनर से प्राप्त किया जाता है और एक निजी चर को सौंपा जाता है। इसके अलावा इस चर का उपयोग किसी भी तरीके या एक्शन कंट्रोलर में किया जा सकता है।
कभी-कभी आप केवल एक एक्शन में इसका उपयोग करने के लिए एक वैरिएबल नहीं बनाना चाहते हैं। तब आप [FromServices] विशेषता का उपयोग कर सकते हैं। एक उदाहरण:

  public IActionResult About([FromServices] IDateTime dateTime) { ViewData["Message"] = «  " + dateTime.Now; return View(); } 

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

थर्ड पार्टी डीआई कंटेनर

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

  public class Operation { public Guid OperationId { get; set; } public Operation() {} } 

जिसे हम लत के रूप में पेश कर सकते हैं,

  services.AddTransient<Operation>(); 

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

तृतीय-पक्ष कंटेनर में अन्य बहुत उपयोगी विशेषताएं हो सकती हैं। उदाहरण के लिए, तीसरे पक्ष के कंटेनर का उपयोग करके, आप केवल उन नियंत्रकों को निर्भरता जोड़ सकते हैं जिनके नाम में एक विशिष्ट शब्द है। और काफी अक्सर इस्तेमाल किया जाने वाला मामला - DI कंटेनर, प्रदर्शन के लिए अनुकूलित।
यहाँ ASP.NET कोर द्वारा समर्थित कुछ तृतीय-पक्ष DI कंटेनरों की एक सूची दी गई है: Autofac, Castle Windsor, LightInject, DryIoC, StructureMap, Unity

हालांकि मानक DI कंटेनर का उपयोग करके, आप संपत्ति / विधि इंजेक्शन का उपयोग नहीं कर सकते हैं, लेकिन आप एक निर्माता के रूप में एक आश्रित पैरामीटर को फैक्ट्री पैटर्न के रूप में लागू कर सकते हैं:

  services.AddTransient<IDataService, DataService>((dsvc) => { IOtherService svc = dsvc.GetService<IOtherService>(); return new DataService(svc); }); 

यदि निर्भर सेवा नहीं मिली है, तो इस स्थिति में, GetService रिक्त हो जाएगी। GetRequiredService की एक भिन्नता है जो एक अपवाद को फेंक देगी यदि निर्भर सेवा नहीं मिली है।
GetService का उपयोग करके एक आश्रित सेवा प्राप्त करने की प्रक्रिया वास्तव में सेवा लोकेटर पैटर्न को लागू करती है।

Autofac

आइए एक व्यावहारिक उदाहरण के साथ ऑटोफैक पर एक नज़र डालें। आसानी से, कंटेनर से सेवाओं को पंजीकृत किया जा सकता है और प्राप्त किया जा सकता है, डिफ़ॉल्ट रूप से और ऑटोफैक का उपयोग करके।

NuGet पैकेज Autofac.Extensions.D dependencyInjection स्थापित करें।
कॉन्फिगरस्वाइस विधि द्वारा दिए गए मान को शून्य से IServiceProvider में बदलें। और संपत्ति जोड़ें

  public IContainer ApplicationContainer { get; private set; } 

उसके बाद, यह स्टार्टअप वर्ग के कॉन्फिगरस्वाइस विधि के अंत में निम्नलिखित की तरह कोड जोड़ना संभव हो जाएगा (यह सेवाओं को पंजीकृत करने के विकल्पों में से एक है):

  services.AddTransient<ISomeRepository, SomeRepository>(); var builder = new ContainerBuilder(); builder.Populate(services); builder.RegisterType<AnotherRepository>().As<IAnotherRepository>(); this.ApplicationContainer = builder.Build(); return new AutofacServiceProvider(this.ApplicationContainer); 

यहाँ बिल्डर। IServiceCollection से कंटेनर में सेवाएँ जोड़ता है। अच्छी तरह से और आगे यह बिल्डर के साथ सेवाओं को पंजीकृत करने के लिए पहले से ही संभव है ।egisterType। अरे हाँ। मैं लगभग भूल गया था। आपको कॉन्फ़िगर से IS ISPProvider के लिए मान को कॉन्फ़िगर कॉन्फ़िगरेशन विधि में बदलना होगा।

ASP.NET कोर के साथ AOP - ऑटोफेक इंटर्सेप्टर्स

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

.NET दुनिया में, एक विधि का उपयोग अक्सर किया जाता है जब AOP कोड पोस्ट प्रोसेसर का उपयोग करके पहले से संकलित एप्लिकेशन कोड ( PostSharp ) में एम्बेडेड होता है। या वैकल्पिक रूप से, आप इंटरसेप्टर का उपयोग कर सकते हैं - ये इवेंट हुक हैं जिन्हें एप्लिकेशन कोड में जोड़ा जा सकता है। ये इंटरसेप्टर, एक नियम के रूप में, डेकोरेटर का उपयोग करते हैं जो हमने उनके काम के लिए पहले ही जांच लिया है।

आइए अपना स्वयं का इंटरसेप्टर बनाएं। सबसे सरल और सबसे विशिष्ट उदाहरण जो पुन: पेश करने में सबसे आसान है वह है लॉगिंग।
Autofac.Extensions.D dependencyInjection पैकेज के अलावा, हम भी Autofac.Extras.DynamicProxy पैकेज स्थापित करेंगे
स्थापित? एक साधारण लॉग क्लास जोड़ें, जिसे कुछ सेवाओं तक पहुँचने पर बुलाया जाएगा।

  public class Logger : IInterceptor { public void Intercept(IInvocation invocation) { Debug.WriteLine($"Calling {invocation.Method.Name} from Proxy"); invocation.Proceed(); } } 

इंटरसेप्टर के हमारे पंजीकरण ऑटोफैक पंजीकरण में जोड़ें:

  builder.Register(i => new Logger()); builder.RegisterType<SomeRepository >() .As<ISomeRepository >() .EnableInterfaceInterceptors() .InterceptedBy(typeof(Logger)); 

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

हम भी हटा सकते हैं। InterceptedBy (टाइपोफ़ (लकड़हारा)); और केवल विशिष्ट एप्लिकेशन सेवाओं के लिए कॉल अवरोधन जोड़ें [इंटरसेप्ट (टाइपोफ़ (लकड़हारा))) विशेषता का उपयोग करते हुए - आपको इसे क्लास हेडर से पहले निर्दिष्ट करना होगा।

middleware

ASP.NET में कोड कॉल की एक विशिष्ट श्रृंखला होती है जो हर अनुरोध पर होती है। यूआई / एमवीसी लोड होने से पहले भी कुछ कार्य किए जाते हैं।

उदाहरण के लिए, यदि हम Startup.cs के कॉन्फ़िगर विधि की शुरुआत में कोड को जोड़ते हैं

  app.Use(async (context, next) => { Debug.WriteLine(context.Request.Path); await next.Invoke(); }); 

तब हम डिबग कंसोल में देख सकते हैं कि हमारे आवेदन अनुरोधों को क्या फाइल करता है। वास्तव में, हमें AOP की क्षमता "आउट ऑफ बॉक्स" होती है
मिडलवेयर का उपयोग करने का थोड़ा बेकार, लेकिन स्पष्ट और जानकारीपूर्ण उदाहरण, अब मैं आपको दिखाऊंगा:

  public void Configure(IApplicationBuilder app) { app.Use(async (context, next) => { await context.Response.WriteAsync("Hello!" + Environment.NewLine); await next.Invoke(); }); app.Run(async context => { await context.Response.WriteAsync("Hello again."); }); } 

प्रत्येक अनुरोध के साथ, कॉल की एक श्रृंखला शुरू होती है। प्रत्येक ऐप से। अगला, अगला कॉल करने के बाद (), अगली कॉल के लिए संक्रमण किया जाता है। और सब कुछ खत्म हो जाता है ऐप के बाद। काम करता है।
आप किसी विशिष्ट मार्ग तक पहुँचने पर ही कुछ कोड निष्पादित कर सकते हैं।
आप app.ap का उपयोग करके ऐसा कर सकते हैं:

  private static void Goodbye(IApplicationBuilder app) { app.Run(async context => { await context.Response.WriteAsync("Goodbye!"); }); } public void Configure(IApplicationBuilder app) { app.Map("/goodbye", Goodbye); app.Run(async context => { await context.Response.WriteAsync("Hello!"); }); } 

अब, यदि आप साइट के पृष्ठ पर जाते हैं, तो आप पाठ "हैलो!" देख सकते हैं, और यदि आप एड्रेस बार में गुडबाय जोड़ते हैं, तो आप गुडबाय देखेंगे।

यूज़ एंड मैप के अलावा, आप कुछ खास परिस्थितियों में ही मिडलवेयर चेन में कोड जोड़ने के लिए UseWhen या MapWhen का उपयोग कर सकते हैं।

अभी तक बेकार उदाहरण हैं, है ना? यहाँ एक सामान्य उदाहरण है:

  app.Use(async (context, next) => { context.Response.Headers.Add("X-Frame-Options", "DENY"); context.Response.Headers.Add("X-Content-Type-Options", "nosniff"); context.Response.Headers.Add("X-Xss-Protection", "1"); await next(); }); 

यहां हम पेज को हैकर के हमलों से बचाने में मदद करने के लिए प्रत्येक अनुरोध में हेडर जोड़ते हैं।

या यहाँ स्थानीयकरण का एक उदाहरण है:

  var supportedCultures = new[] { new CultureInfo("ru"), new CultureInfo("fr") }; app.UseRequestLocalization(new RequestLocalizationOptions { DefaultRequestCulture = new RequestCulture("ru"), SupportedCultures = supportedCultures, SupportedUICultures = supportedCultures }); 

अब यदि आप पैरामीटर जोड़ते हैं? संस्कृति = पृष्ठ पते पर फ़्री, तो आप एप्लिकेशन भाषा को फ़्रेंच पर स्विच कर सकते हैं (यदि आपके आवेदन में स्थानीयकरण जोड़ा जाता है, तो सब कुछ काम करेगा)

फिल्टर

यदि मिडलवेयर श्रृंखला MVC से पहले की प्रक्रियाओं को संदर्भित करती है, तो फ़िल्टर MVC के साथ मिलकर काम करते हैं।
निम्न योजनाबद्ध आरेख दिखाता है कि फ़िल्टर कैसे काम करते हैं।

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

फिर वे संसाधन फ़िल्टर पूरा करते हैं। इन फ़िल्टरों का उपयोग करके, आप उदाहरण के लिए, कैश से कुछ जानकारी वापस कर सकते हैं।

फिर डेटा बाइंडिंग होती है और एक्शन फिल्टर निष्पादित होते हैं। उनकी मदद से, आप कार्रवाई में दिए गए मापदंडों और वापस किए गए परिणाम में हेरफेर कर सकते हैं।

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

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

. :

  public class YourCustomFilter : Attribute, IAuthorizationFilter { public async void OnAuthorization(AuthorizationFilterContext context) { // -    ,     ,    context.Result = new ContentResult() { Content = "        " }; } } 

DI ( Startup.cs)

  services.AddScoped<YourCustomFilter>(); 

- Action

  [ServiceFilter(typeof(YourCustomFilter))] 

– middleware - action . Configure

  public class MyMiddlewareFilter { public void Configure(IApplicationBuilder applicationBuilder) { applicationBuilder.Use(async (context, next) => { Debug.WriteLine("  middleware!"); await next.Invoke(); }); } } 

Action-

  [MiddlewareFilter(typeof(MyMiddlewareFilter))]