2015-03-07 7 views
11

मैं यह समझने की कोशिश कर रहा हूं कि एएसपी.नेट 5 पाइपलाइन मिडलवायर वास्तव में कैसे काम करते हैं। एक मिडलवेयर, जैसा कि मुझे पता है, सिर्फ Func<RequestDelegate, RequestDelegate> है, जो कि एक विधि के लिए एक सूचक है जो अगले अनुरोध प्रतिनिधि का संदर्भ प्राप्त करता है और अगले को लपेटता है जो एक नया लौटाता है। हम निश्चित रूप से, एक मिडलवेयर प्रतिनिधित्व करने के लिए एक वर्ग का उपयोग कर सकते हैं, कुछ की तरह:एक मिडलवेयर हमेशा अगली बार आना चाहिए?

public class MyMiddleware 
{ 
    private readonly _next; 

    public MyMiddleware(RequestDelegate next) 
    { 
     if (next == null) 
     { 
      throw new ArgumentNullException("next"); 
     } 

     _next = next; 
    } 

    public Task Invoke(HttpContext context) 
    { 
     // New request delegate code here which can wrap the next one on the pipeline 
    } 
} 

RequestDelegate के बाद से एक प्रतिनिधि है कि तरीकों जो एक HttpContext प्राप्त करता है के लिए संदर्भ पकड़ और एक TaskInvoke विधि रिटर्न कर सकते हैं अनुरोध प्रतिनिधि है वापस लौटने के लिए और जिसकी पाइपलाइन पर अगले व्यक्ति तक पहुंच है।

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

  • चेक अगर मिडलवेयर अनुरोध
  • संभाल सकता है यह, जो कुछ भी साथ HttpContext
  • कॉल अगले किया जाना चाहिए कर सकते हैं पाइपलाइन

तो जब मैंने पहली बार यह अध्ययन किया तो मैंने सोचा कि प्रत्येक मिडलवेयर हमेशा अगले को कॉल करना चाहिए। लेकिन ऐसा करने से अजीब व्यवहार हुआ क्योंकि this question पर चर्चा की गई।

इसके अलावा कुछ middlewares मैं देख रहा हूँ उनमें से कुछ एक और चरणों का पालन करें की स्रोत कोड देख:

  • चेक अगर मिडलवेयर अनुरोध
  • संभाल सकता है यह, जो कुछ भी साथ किया जाना चाहिए कर सकते हैं HttpContext और कहा कि सभी
  • यदि नहीं, तो है और केवल नहीं करता है, तो कॉल अगले एक

यह असली मैं है midwares का उपयोग करने के डीए? इस पर सही दृष्टिकोण किस तरह से है? प्रत्येक मिडलवेयर अनुरोध के साथ क्या किया जाना चाहिए और हमेशा अगली आग्रह करें या अगर मिडलवेयर अनुरोध को संभाल सकता है तो यह अगली बार नहीं आ सकता है?

मेरा मानना ​​है कि एक मिडलवेयर को केवल अगली कॉल करना चाहिए यदि वह अनुरोध को संभाल नहीं सकता है। कारण मुझे लगता है कि ऐसा इसलिए है क्योंकि यदि नहीं, तो पाइपलाइन पर मध्यवर्ती के बीच युग्मन होगा। ताकि अनुरोध को संसाधित करने के लिए मिडलवेयर को जागरूक होने की आवश्यकता होगी कि पिछले किसी ने सबकुछ खराब करने से बचने के लिए क्या किया था। क्या यह निष्कर्ष सही है?

उत्तर

15

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

एक मिडलवेयर कर सकते हैं:

  1. कुछ न करें और अनुरोध आगे पारित (जैसेएक मिडलवेयर कि केवल पोस्ट अनुरोध के लिए लागू है लेकिन मौजूदा एक मिल है)
  2. अनुरोध लिए कुछ भी नहीं करते हैं, (उदाहरण के लिए प्रवेश और कुछ बजाय कुछ करने और इसे आगे पारित)
  3. अनुरोध करने के लिए कुछ करो और पारित आगे अनुरोध करें (उदाहरण के लिए एक प्रमाणीकरण टोकन प्राप्त करें और इसे किसी पहचान में परिवर्तित करें, या अनुरोध से कुछ संवेदनशील जानकारी हटाएं)
  4. पाइपलाइन समाप्त करें और अनुरोध को आगे न भेजें (उदाहरण के लिए StaticFileMiddleware जो रूट या फ़ाइल के दौरान एमवीसी देता है मैचों)

शायद उत्तर देने वाला वाई हमारे other question भी: दो प्रकार के मिडलवेयर हैं:

  1. मिडलवेयर जो कुछ करने के लिए डिज़ाइन किए गए हैं और आगे के साथ डेटा पास करते हैं। ऑथ, कुकीज़, सत्यापन, लॉगिंग इत्यादि)
  2. पाइपलाइन (स्थिर फ़ाइल, एमवीसी, आदि) को पूरा करने वाले मिडलवेयर।

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

मिडलवेयर के लेखक को यह तय करना होगा कि अगला मिडलवेयर (यदि कोई है) को बुलाया जाना चाहिए या नहीं। आपके प्रश्न में मिडलवेयर के मामले में जो एक संदेश देता है, उसे अगले को नहीं बुलाया जाना चाहिए।

संबंधित मुद्दे