Asp.Net Wprowadzenie IHttpHandler
ASP.NET dwa najczęściej używane interfejsy przetwarzające podczas odpowiadania na żądania Http to IHttpHandler i IHttpModule.
Ogólnie rzecz biorąc, IHttpHandler służy do obsługi określonego typu żądań, takich jak oddzielne przetwarzanie każdego pliku *.asp, *.aspx. IHttpModule jest zwykle używany do obsługi operacji często wymaganych dla żądania, takich jak wykonywanie niektórych tych samych kontroli na stronie żądania.
Przyjrzyjmy się krokom przetwarzania na serwerze IIS podczas wysyłania odpowiadającego żądania HTTP. ASP.NET posiada koncepcję potokowego, co oznacza, że każde ASP.NET żądanie będzie miało serię odpowiadających im operacji w IIS, tworząc sekwencję liniową.
ASP.NET wprowadzenie do pipeline'u
Przyjrzyjmy się diagramowi czasowemu przetwarzania w potoku:
Jak widać na rysunku, po nadejściu żądania implementacja jest przetwarzana przez HttpModule, a następnie wywoływana jest metoda ProcessRequest() w HttpHandler, aby wykonać konkretną odpowiedź. Dlatego łatwo zrozumieć, dlaczego obsługa zapytań specyficznych dla klasy jest umieszczona w klasie HttpHandler, jednocześnie wykonując pewne kontrole wspólne dla wszystkich żądań w HttpModule.
Praktyka kodowania
IHttpHandler
Autor niedawno natknął się na użycie IHttpHandler do obsługi wywołań interfejsu klienta w projekcie, więc krótko omówmy prosty projekt interfejsu oparty na IHttpHandler.
Interfejs IHttpHandler ma tylko dwa elementy:
Atrybut IsReusable identyfikuje, czy obiekt HttpHandler może być używany przez inne instancje i zazwyczaj ustawiamy go na True. Metoda ProcessRequest() jest konkretną odpowiedzią na żądanie i wystarczy umieścić tutaj konkretną operację logiki biznesowej.
Najpierw stwórz nowy projekt webowy i dodaj klasę Handler:
Klasa RayHandler implementuje funkcję ProcessRequest() interfejsu IHttpHandler, która jest po prostu bezpośrednim wyjściem fragmentu tekstu.
Następnie musimy dodać następującą konfigurację w pliku Web.config:
path oznacza dopasowanie URL, np. *.ray, co oznacza, że Handler odpowiada na żądania URL kończące się na ".ray", verb oznacza metodę żądania, np. Get/Post, a * oznacza, że pasuje do wszystkich. type wskazuje typ klasy Handler, WebApplication2. RayHandler to nazwa klasy, WebApplication2 odnosi się do nazwy asemblera w katalogu Bin, na przykład nazwa asemblera w przykładzie to WebApplication2.dll i nie ma potrzeby definiowania tutaj nazwy sufiksu.
Uruchom stronę, wpisz adres URL kończący się na ".ray" i zobaczysz następujący wynik:
Przegląd IHttpHandlerFactory
Czasami musimy mieć do czynienia z wieloma różnymi sufiksami, z których jeden odpowiada klasie Handler, i tak wygląda nasz plik Web.config:
Jeśli mamy dużo klas implementacyjnych HttpHandler, to konfiguracja pliku Web.config będzie wyglądać na rozwlekłą. A w niektórych przypadkach, gdy możemy określić tylko to, który Handler odpowiada podczas działania programu, musimy użyć IHttpHandlerFactory.
IHttpHandlerFactory jest definiowany następująco:
Wśród nich:
GetHandler(): Zwraca instancję implementującą interfejs IHttpHandler;
ReleaseHandler(): Umożliwia Factory ponowne wykorzystanie istniejącej instancji Handlera.
Weźmy powyższe żądania promienia i rss jako przykład, zaimplementuj klasę Factory:
W tym przypadku konfiguracja w Web.config wygląda następująco:
Obecnie implementowano funkcję wykorzystania klasy Factory do odpowiadania różnym konkretnym handlerom, co upraszcza konfigurację.
Skalowalna IHttpHandlerFactory
W powyższej implementacji, jeśli program będzie musiał dodać nową metodę obsługi sufiksów w przyszłości, musi zmodyfikować polecenie Switch w GetHandler(), co również może powodować błędy lub stwarzać inne zagrożenia bezpieczeństwa. Czy więc możliwe jest zachowanie klasy HandlerFactory bez zmian w kolejnych rozszerzeniach?
Odpowiedź brzmi zdecydowanie tak. Czytelnicy zaznajomieni z wzorcem projektowym powinni rozumieć, że jest to prosty wzór fabryczny, a aby osiągnąć poprzednie funkcje, możemy użyć trybu projektowania zwanego zaawansowanymi punktami.
Tutaj możemy także wykorzystać funkcję językową języka C# – refleksję. Dzięki mechanizmowi refleksji C# odzwierciedlamy odpowiadający mu typ Händera zgodnie z sufiksem URL, pod warunkiem że zgadzamy się co do zgodności między nazwą sufiksu URL a nazwą klasy Handlera.
Na przykład przepisujemy GetHandler() w następujący sposób:
W takim przypadku wystarczy umieścić klasę Handler w metodzie pod tą samą przestrzenią nazw co klasa HandlerFactory i poprawnie ją skonfigurować w Web.config. Na przykład, jeśli istnieje klasa RayHandler, należy dodać następującą konfigurację, aby automatycznie dopasować:
streszczenie
Ten artykuł krótko wprowadza zastosowanie IHttpHandler w ASP.NET, umożliwia implementację IHttpHandlerFactory w przetwarzaniu wielu żądań Handlerów oraz wreszcie usprawnia skalowalną implementację Handlera z wieloma żądaniami wykorzystującą mechanizm refleksji C#.
|
Opublikowano 13.03.2018 21:40:17
|
|
|
|
