Каковы преимущества использования HTTPHandler по сравнению с .aspx? Обладает ли он теми же возможностями, легче и быстрее?
Каковы некоторые из недостатков?
HTTPHandler против .aspx
comment
Хороший вопрос, но почти наверняка обман, и он широко обсуждается и легко гуглится.
- person annakata schedule 18.08.2010
Ответы (4)
Aspx использует полнофункциональную веб-форму со сложным жизненным циклом страницы и большим количеством дополнительной обработки. HttpHandler чистый и легкий. Он имеет только функциональность, которую вы реализуете.
person
Ladislav Mrnka
schedule
17.08.2010
Помните, что когда ваша страница .aspx будет скомпилирована, она будет преобразована в класс, прямо или косвенно производный от System.Web.UI.Page (путем наследования от класса с программным кодом, который, в свою очередь, прямо или косвенно наследуется от Page.
Page реализует IHttpHandler, так что вы всегда будете использовать IHttpHandler.
И быстрый просмотр списка членов Page дает хороший ответ на этот вопрос. Много чего происходит, и многое предлагается для получения классов (то есть для файлов .aspx и кода позади). И это до того, как мы рассмотрим, как анализируются файлы .aspx, чтобы упростить написание кода с большим количеством «шаблонного» кода в них.
Вы потеряете все это, если напишете свой собственный обработчик. Его потеря даст вам прирост производительности, но не так сильно, как вы думаете, многого не стоит, если он не используется. Действительно, если вы потеряете то, что вам нужно, ваши собственные методы вернуть его могут оказаться менее эффективными.
Если естественный способ написания рассматриваемого обработчика состоит в том, чтобы все происходило прямо или косвенно (вызов метода) из одного обработчика событий в вашем коде программной части и с пустым .aspx, тогда может быть понятнее написать его как вместо этого обработчик, и в этом случае сделайте. В противном случае вы хотите придерживаться файла .aspx.
person
Jon Hanna
schedule
17.08.2010
Под .aspx вы действительно подразумеваете экземпляр System.Web.UI.Page, который, как вы можете видеть в метаинформации для этого класса, является реализацией IHttpHandler, другими словами (грубо говоря) экземпляр Page is< /em> HttpHandler (в этом, скорее, суть) плюс целая куча вещей, которые придают ему поведение страницы.
Таким образом, разница в том, что с помощью Page вы можете использовать все, что она вам дает (состояние просмотра, управляемость, жизненный цикл и т. д.) за счет необходимости иметь все эти накладные расходы независимо от того, нужно ли вам это. или нет, по сравнению с написанием собственной реализации, где вы можете сделать ее настолько легкой и подходящей для цели, которую вы выберете, за счет необходимости писать все это самостоятельно.
Таким образом, HttpHandler особенно подходит, когда вы не заинтересованы в поддержке страницы, потому что вы не предоставляете семантический ответ страницы — почти наверняка будет ошибкой доставлять XML, JSON, изображения или что-либо еще, кроме разметки в стиле HTML с помощью страницы. .
На практике я выбираю третий вариант — MVC — большую часть времени :)
person
annakata
schedule
17.08.2010
В зависимости от того, что делает страница/обработчик, у меня было повышение производительности от 5 до 15% с использованием простых обработчиков вместо страниц — они часто являются хорошим выбором для создания изображений, json и т. д., обработки фоновых задач из запросов ajax или выполнения такие вещи, как регистрация посетителей по запросам изображений.
Обработчики немного болезненны в использовании, если вы пишете много HTML-кода - вероятность ошибок при построении строк HTML часто перевешивает преимущества в производительности.
Одна существенная вещь, которую вы теряете с обработчиком, — это простое кэширование с объявлением кеша вывода — вы, конечно, можете подключить его самостоятельно программно, но я обнаружил, что aspnet обычно лучше справляется с управлением кешем, чем все, что я пишу быстро.
person
seanb
schedule
17.08.2010
