Conducta evenimentului pentru aplicații nu se limitează la cereri la formularele web .aspx. Este, de asemenea, utilizat în cazul în care sunt create specialiști care oferă tipuri speciale de fișiere.
De ce ar trebui să creați un handler special? În majoritatea cazurilor acest lucru nu este necesar. Cu toate acestea, este uneori convenabil să aveți o interfață la nivel scăzut, care încă permite accesul la obiecte utile, cum ar fi răspunsul și solicitarea, dar nu utilizează întregul model al formularului web cu numeroasele sale controale.
Arhitectura plug-in ASP.NET face posibilă implementarea acestor scripturi remarcabil de simplu. De exemplu, operatorii noi pentru tipuri speciale de fișiere pot fi "conectați" pur și simplu prin adăugarea parametrilor de configurare corespunzători. Cu toate acestea, mai întâi trebuie să înțelegeți cum funcționează conducta HTTP.
HTTP Handlers
Fiecare cerere venită la aplicația ASP.NET este gestionată de o componentă special concepută, numită manipulatorul HTTP. Operatorii HTTP joacă un rol central în structura de procesare a interogărilor ASP.NET. Pentru a gestiona fișiere de diferite tipuri în ASP.NET diferite sunt utilizate HTTP manipulatoare. De exemplu, pentru paginile web, se utilizează un handler care creează obiectele paginii și comenzile, rulează codul și vizualizează codul HTML final.
Puteți să vă înregistrați handlerele HTTP în două moduri. Dacă utilizați un server Web încorporat în Visual Studio, o versiune mai veche a IIS sau o versiune IIS 7.x în modul clasic, manipulatoarele HTTP trebuie adăugate la secțiunea
În interiorul secțiunii
Când se utilizează IIS 7.x în modul integrat (modul implicit), metoda de înregistrare a agendei HTTP de mai sus nu funcționează. În această situație, IIS citește partiția
Ca și secțiunea
Dezavantajul acestei abordări este că întregul proces depinde de înregistrarea inițială a dosarului. Dacă motorul ASP.NET nu este înregistrat pentru un anumit tip de fișier, un handler special sau un modul HTTP nu va putea să ruleze atunci când solicită un fișier de acest tip.
Versiunea IIS 7.x este mai inteligentă. În modul integrat, se ocupă de sarcina de a trimite o solicitare la un handler HTTP adecvat și întotdeauna citește informații despre operatorii de la secțiunea
Crearea unui handler personalizat HTTP
Dacă doriți să lucrați la un nivel inferior celui pe care modelul de formular web îl oferă pentru a oferi un tip de procesare specializat, puteți implementa propriul handler HTTP.
Pentru a construi un handler HTTP special, creați pur și simplu o clasă care implementează interfața IHttpHandler. Această clasă poate fi plasată în directorul App_Code sau compilată ca parte a unui ansamblu autonom al DLL (cu alte cuvinte, ca proiect de bibliotecă de clasă separată) și a adăugat o legătură într-o aplicație web.
Interfața IHttpHandler necesită doi membri din clasa de implementare:
ASP.NET apelează această metodă când se primește o solicitare. Aici lucrătoarele HTTP efectuează toate lucrările. Puteți accesa obiectele interne ASP.NET (cum ar fi Cerere, Răspuns și Server) utilizând obiectul HttpContext transmis acestei metode
După ce metoda ProcessRequest () și-a finalizat activitatea, ASP.NET verifică această proprietate pentru a vedea dacă această instanță a handlerului HTTP poate fi reutilizată. O valoare adevărată indică faptul că obiectul handler HTTP poate fi refolosit pentru o altă interogare de același tip, iar false este că obiectul handler HTTP ar trebui să fie abandonat
Următoarea este un exemplu de creare a unui handler HTTP simplu. Pur și simplu returnează un bloc fix de marcare HTML cu mesajul:
Dacă creați această extensie ca proiect de bibliotecă de clasă, va trebui să adăugați o referință la ansamblul System.Web.dll care conține un număr mare de clase ASP.NET. Fără această legătură, nu puteți utiliza tipuri precum IHttpHandler și HttpContext.
Configurarea unui handler personalizat HTTP
După ce clasa handlerului HTTP este creată și pusă la dispoziția aplicației web (prin plasarea acesteia în directorul App_Code sau prin adăugarea unui link), extensia este gata de utilizare. Următorul pas este să modificați fișierul web.config pentru aplicația Web pentru a înregistra dispozitivul de tratare HTTP. Un exemplu este prezentat mai jos:
Când înregistrați un handler HTTP, sunt specificate trei detalii importante. Atributul de verb specifică tipul de solicitare HTTP - POST sau GET (pentru toate tipurile de interogări *). Atributul căii indică extensia de fișier pe care o va apela handlerul HTTP. În acest exemplu, secțiunea web.config asociază clasa SimpleHandler cu numele fișierului test.simple.
În cele din urmă, atributul de tip identifică clasa manipulatorului HTTP. Această identificare constă din două părți. Prima parte reprezintă numele de clasă complet calificat (în acest exemplu - HttpExtensions.SimpleHandler). Această parte este urmată de o virgulă și numele fișierului DLL al ansamblului care conține această clasă (în acest exemplu - HttpExtensions.dll). Rețineți că extensia .dll este întotdeauna asumată, deci nu trebuie să o specificați.
Dacă utilizați o abordare cu App_Code în loc de un ansamblu compilat separat, în general, puteți omite numele fișierului DLL, deoarece ASP.NET îl va genera automat.
Utilizând agenți de procesare HTTP care nu trebuie să fie configurați
În ASP.NET sprijinit, de asemenea, o abordare alternativă care evită înregistrarea HTTP și nu manipulare vă faceți griji cu privire la modul în care se configurează setările în fișierul de configurare - Utilizați o extensie .ashx recunoscută. Indiferent (chiar și Visual Studio server de web integrat) versiunea de IIS nu este utilizat, toate cererile de prelungire se încheie .ashx, este tratat în mod automat ca cereri deservite de handler speciale HTTP.
Pentru a crea un fișier .ashx în Visual Studio, selectați Adăugați un element nou din meniul Site (sau din meniul Project pentru proiectul Web) și selectați Generic Handler. Apoi, introduceți un nume potrivit și dați clic pe butonul Adăugați pentru a crea un handler.
Fișierul .ashx începe cu directiva WebHandler. Această directivă indică clasa care ar trebui furnizată prin intermediul acestui fișier. De exemplu:
Numele clasei poate corespunde clasei din directorul App_Code sau clasei din ansamblul referință. Alternativ, puteți defini clasa direct în fișierul .ashx (conform directivei WebHandler). În orice caz, atunci când utilizatorul solicită un fișier .ashx, se va executa clasa handler corespunzătoare HTTP. Dacă salvați exemplul anterior ca fișier simple.ashx, atunci atunci când un client simple.ashx îl solicită, va fi executat un handler special de web. Mai mult decât atât, tipul fișierului .ashx este înregistrat în IIS, deci nu trebuie să configurez IIS la implementarea aplicației.
Utilizați un fișier de configurare sau un fișier .ashx este o chestiune de preferință personală. Cu toate acestea, fișierele .ashx sunt de obicei folosite pentru extensii mai simple, care sunt dezvoltate pentru o singură aplicație Web. Fișierele de configurare oferă, de asemenea, un anumit grad de flexibilitate. De exemplu, puteți înregistra un handler HTTP pentru a lucra cu interogări care se termină cu această extensie, în timp ce fișierul .ashx va difuza cererea cu un anumit nume de fișier.
De asemenea, puteți înregistra un handler HTTP pentru mai multe aplicații (prin înregistrarea acestuia în fișierul web.config și instalarea ansamblului în GAC). Pentru a obține același efect cu fișierul .ashx, va trebui să copiați fișierul .ashx în fiecare director virtual.
Crearea unui handler HTTP mai funcțional
În exemplul anterior, procesatorul HTTP a returnat pur și simplu un bloc de marcare statică HTML. Cu toate acestea, este, de asemenea, acceptabil să se creeze agenți mai complicați. De exemplu, puteți citi datele trimise către pagină sau specificate în șirul de interogare și le puteți aplica pentru a personaliza datele de ieșire generate. Următoarea este un exemplu de afișare a codului sursă pentru fișierul solicitat. Utilizează suport I / O pentru un fișier din spațiul de nume System.IO.
Acest cod găsește pur și simplu fișierul dorit, citește conținutul acestuia și aplicând un înlocuitor de șir mic (de exemplu, înlocuirea spațiului gol cu spații fără rupere și întreruperi de linii de către un element
) și codarea HTML construiește o vizualizare afișată în siguranță în browser.
Acum, puteți să cartografiați dispozitivul handler la extensia de fișier:
După aceasta, handler-ul HTTP va afișa codul sursă pentru fișierul .cs:
Crearea unui handler HTTP pentru alt conținut decât HTML
Unele dintre cele mai interesante dispozitive HTTP nu generează conținut HMTL, ci conținut de alte tipuri, de exemplu imagini. Acest lucru face posibil să nu se bazeze pe fișiere fixe, ci să extragă sau să genereze conținut în mod programatic. De exemplu, puteți citi conținutul unui fișier ZIP mare dintr-o intrare din baza de date și utilizați metoda Response.BinaryWrite () pentru ao trimite clientului.
Puteți chiar să vă deplasați și să construiți un handler HTTP pentru a crea dinamic o arhivă ZIP compusă din mai multe fișiere mai mici. În ambele cazuri, pentru un client care utilizează un handler HTTP, totul va arăta ca și cum browserul va încărca un fișier obișnuit, deși conținutul este difuzat folosind codul ASP.NET.
Dacă pagina care utilizează imaginea este pe un alt site, există o posibilă problemă. Această pagină nu numai că fure imaginea dvs., ci creează, de asemenea, o încărcare suplimentară pe serverul dvs. Motivul este că ori de câte ori cineva scanează acest alt site, este cerută o imagine de la serverul dvs. Dacă imaginea furată apare pe un anumit site popular, încărcarea suplimentară pe server poate fi foarte mare și poate reduce foarte mult lățimea de bandă necesară pentru a vă păstra propriile pagini.
Această problemă - furtul de lățime de bandă prin legături către resursele de pe serverul dvs. - este denumit informal leeching. Este sursa principală de "dureri de cap" pentru site-urile populare care deservesc cantități uriașe de conținut non-HTML (de exemplu, site-uri de partajare a fotografiilor, cum ar fi Flickr). Multe site-uri web contracarează această problemă în același mod ca și handlerul HTTP descris mai jos, și anume, refuză să servească imaginea sau să o înlocuiască cu o figură fictivă dacă titlul paginii de referință indică faptul că cererea a venit de pe un alt site Web.
Mai jos este un handler HTTP care implementează această soluție în ASP.NET. Pentru a utiliza acest cod, va trebui să importați spațiile de nume System.Globalization și System.I0:
Pentru ca acest handler să protejeze fișierele imagine, trebuie să fie înregistrat pentru a păstra fișierele de tipuri corespunzătoare. Următoarele sunt parametrii din fișierul web.config care configurează manualul pentru întreținerea fișierelor de tip .gif și .png:
Bazându-vă pe exemplul de mai sus, vă puteți gândi la multe alte modalități de a utiliza dispozitivele de tratare HTTP: de exemplu, le puteți folosi pentru a face imagini speciale, pentru a efectua interogări speciale în baza de date sau chiar pentru a returna date binare. Toate aceste exemple extind arhitectura ASP.NET, dar depășesc modelul de pagini web. Ca urmare, se obțin componente mai compacte și mai eficiente.
De asemenea, puteți crea agende HTTP care funcționează în modul asincron. Aceasta înseamnă că pentru a-și îndeplini activitatea, ei creează un fir nou și nu utilizează unul dintre fluxurile de lucru ASP.NET. Această tehnică îmbunătățește scalabilitatea în situațiile în care trebuie îndeplinită o sarcină care consumă mult timp, dar care nu necesită multe resurse CPU (CPU). Un exemplu clasic poate fi așteptarea citirii unei resurse de rețea extrem de lentă.
Numărul de fluxuri de lucru care pot fi difuzate în ASP.NET în același timp este fix (și este, de obicei, 25). Când se atinge această limită, cererile suplimentare vor fi plasate în coadă, chiar dacă timpul CPU-ului este gratuit. Datorită administratorilor asincroni, pot fi primite cereri suplimentare, deoarece aceștia pot crea un fir nou pentru fiecare solicitare și nu utilizează fluxul de lucru.
Desigur, această abordare este asociată cu un anumit risc: atunci când creați prea multe fire sau atunci când încercați să executați prea multe sarcini simultan consumând o mulțime de resurse CPU, performanța întregului server web va suferi în mod serios.
Articole similare
Trimiteți-le prietenilor: