HTTPHandler vs .aspx

Question

Jakie są zalety używania HTTPHandler kontra .aspx? Czy ma te same możliwości i jest lżejszy i szybszy?

Jakie są wady?

Answer 1

Firma Aspx używa pełnowartościowego internetowego formularza o złożonym cyklu życia strony i wielu dodatkowych czynnościach. HttpHandler jest czysty i lekki. Ma tylko funkcje, które stosujesz.

Answer 2

Przez .aspx naprawdę chodzi o instancję System.Web.UI.Page, która jak widać w meta-informacji dla tej klasy jest implementacją IHttpHandler - innymi słowy (w przybliżeniu mówiąc) instancją strony jest HttpHandler (jest to raczej punkt) plus cała masa rzeczy, które daje mu zachowanie strony.

Różnica polega na tym, że za pomocą strony możesz wykorzystać wszystkie rzeczy, które ci daje (stan oglądania, kontrola, cykl życia, itp.) Kosztem posiadania całego tego obciążenia, niezależnie od w zależności od tego, czy tego potrzebujesz, czy nie, zamiast pisania własnej implementacji, w której możesz zrobić to tak lekki i dopasowany do celu, jaki wybierzesz, kosztem konieczności napisania go samemu.

HttpHandler jest szczególnie przydatny, gdy nie interesuje Cię obsługa stron, ponieważ nie dostarczasz semantycznej odpowiedzi strony - prawie na pewno jest to błędem dostarczanie XML, JSON, obrazów lub czegokolwiek innego niż znak HTML za pomocą strony.

W praktyce wybrać trzecią opcję - MVC - większość czasu :)

Answer 3

Pamiętaj, że gdy strona aspx jest kompilowany, zostanie on przekształcony w klasie, która wywodzi się z System.Web.UI.Page bezpośrednio lub pośrednio (przez inheritting z klasy „kodu źródłowego”, który z kolei jest bezpośrednio lub pośrednio inheritted z Page.

Page realizuje IHttpHandler, więc nigdy nie używasz IHttpHandler.

i szybki skanera na członek li st Page daje własną dobrą odpowiedź na to pytanie. Wiele się dzieje i wiele jest oferowanych do wyprowadzania klas (to znaczy do plików .aspx i do kodowania z tyłu). I to zanim rozważymy sposób, w jaki pliki .aspx są przetwarzane, aby napisać kod z dużą ilością "szablonu" kodu w bardzo prosty sposób.

Tracisz wszystko, jeśli napiszesz własny przewodnik. Utrata go spowoduje wzrost wydajności, ale nie tak dużo, jak mogłoby się wydawać, wiele nie kosztuje, jeśli nie jest używany. Rzeczywiście, jeśli stracisz rzeczy, których potrzebujesz, twoje własne metody odzyskania mogą być mniej wydajne.

Jeśli naturalnym sposobem napisania danego programu obsługi byłoby wszystko, co dzieje się bezpośrednio lub pośrednio (wywołanie metody) z pojedynczej procedury obsługi zdarzenia w kodzie z tyłu i z pustym .aspx, wtedy może być jaśniejsze zamiast tego napisać go jako program obsługi, w takim przypadku wykonaj. W przeciwnym razie chcesz trzymać się pliku .aspx.

Answer 4

W zależności od tego, co robi strona/program obsługi, miałem od 5 do 15% zwiększenia wydajności, używając zwykłych programów obsługi zamiast stron - są one często dobrym wyborem do generowania obrazów, json itp., Obsługując zadania w tle z ajax żądania lub robienie rzeczy takich jak rejestrowanie gości z żądań obrazów.

Obsługa jest trochę bolesna w użyciu, jeśli piszesz dużo html - potencjalne błędy w budowaniu ciągów znaków html często przewyższają zalety wydajności.

Jedna ważna rzecz, którą utraciłeś z handler'em, to bezmyślne buforowanie z deklaracją ouput cache - możesz oczywiście podłączyć ją programowo, ale odkryłem, że aspnet zazwyczaj lepiej zarządza pamięcią podręczną niż cokolwiek innego. Piszę szybko.