2015-03-07 11 views
11

Próbuję zrozumieć, jak naprawdę działa oprogramowanie pośrednie potoku ASP.NET 5. Jak wiadomo, oprogramowanie pośredniczące to po prostu Func<RequestDelegate, RequestDelegate>, które jest wskaźnikiem dla metody, która odbiera odwołanie do następnego delegata żądania i zwraca nowy, który opakowuje następny. Możemy oczywiście użyć klasy do reprezentowania middleware, coś jak:Oprogramowanie pośredniczące powinno zawsze wywoływać następne?

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 
    } 
} 

Od RequestDelegate jest delegatem, który może pomieścić odniesień do metod, które otrzymuje jeden HttpContext i zwraca Task metodę Invoke jest delegatem żądanie do zwrotu i który ma dostęp do następnego na rurociągu.

Mamy wtedy, przy kodowaniu oprogramowania pośredniego, dostęp do następnego komponentu potoku, ale mam wątpliwości. Na początku myślałem, że ideałem było zawsze pracować w następujący sposób:

  • Sprawdź, czy middleware może obsłużyć żądania
  • Jeśli może, robić, co należy zrobić z HttpContext
  • połącz się z następną oprogramowanie pośredniczące na potoku

Tak więc, kiedy po raz pierwszy przestudiowałem to, pomyślałem, że każde oprogramowanie pośrednie powinno zawsze wywoływać następne. Ale zrobienie tego doprowadziło do dziwnych zachowań, o których była mowa w artykule this question.

Również patrząc na kod źródłowy niektórych middleware widzę niektóre z nich śledzić kolejne etapy:

  • Sprawdź, czy middleware może obsłużyć żądania
  • Jeśli może, robić, co należy zrobić z HttpContext i to wszystko
  • Jeśli nie, i tylko wtedy, gdy nie wezwanie następny

Czy to prawdziwe ja dea korzystania z middleware? Którędy jest właściwe podejście? Każde oprogramowanie pośrednie robi to, co należy zrobić z żądaniem i zawsze wywołuje następne, lub czy oprogramowanie pośrednie może obsłużyć żądanie, które nie wywołuje już następnego?

Uważam, że oprogramowanie warstwy pośredniej powinno wywoływać następne tylko wtedy, gdy nie może obsłużyć żądania. Powodem, dla którego myślę, że to dlatego, że gdyby nie, to byłoby połączenie między middleware w rurociągu. Aby przetworzyć żądanie, oprogramowanie pośrednie musiało być świadome tego, co zrobił poprzedni, aby uniknąć wszystkiego. Czy ten wniosek jest właściwy?

Odpowiedz

15

Oprogramowanie pośredniczące umożliwia ręczne przesyłanie żądań, co oznacza, że ​​można dodawać/usuwać/wymieniać części z niego, o ile przestrzega się umowy. Na przykład, jeśli aplikacja obsługuje niektóre pliki bez buforowania, można dodać oprogramowanie pośrednie z przodu potoku bez zmiany reszty. To są klocki.

middleware może:

  1. rób nic i dalej przekazać żądanie (npmiddleware, który ma zastosowanie jedynie do żądań POST ale aktualna jest GET)
  2. rób nic do wniosku, zamiast robić coś innego i przekazać ją dalej (na przykład rejestrowanie)
  3. coś zrobić, aby wniosek i przekazać zażądać dalszych informacji (np. uzyskać token uwierzytelniający i przekonwertować go na tożsamość lub usunąć niektóre informacje poufne z żądania).
  4. Zakończ rurociąg i nie przekazuj dalej żądania (np. StaticFileMiddleware, który właśnie zwrócił plik, lub MVC, gdy trasa mecze)

Prawdopodobnie odpowiada za także nasz other question: istnieją dwa rodzaje oprogramowania pośredniego:

  1. Oprogramowanie pośrednie zaprojektowane do robienia czegoś i przekazywania danych dalej (itp. auth, pliki cookie, sprawdzanie poprawności, rejestrowanie itp.)
  2. Oprogramowanie pośrednie uzupełniające potok (plik statyczny, MVC itp.).

Oczywiście niektóre z nich mogą działać w obu kontekstach. Na przykład auth może zakończyć potok, jeśli poświadczenia są niepoprawne, ale kontynuować w inny sposób.

Autor oprogramowania pośredniego musi zdecydować, czy należy uruchomić następne oprogramowanie pośrednie (jeśli istnieje). W przypadku oprogramowania pośredniego, które zwraca komunikat, nie powinno ono wywoływać następnego.

Powiązane problemy