Как запускается веб-приложение? Где точка входа (если есть)?

Я использую IIS для разработки некоторых веб-приложений. Раньше я полагал, что каждое приложение должно иметь точку входа. Но похоже, что у веб-приложения нет такого.

Я прочитал много книг и статей, посвященных тому, как создать приложение ASP.NET в IIS, но они просто не рассматривают наиболее очевидную и основную вещь, которую я хочу знать.

Так может ли кто-нибудь сказать мне, как начинается веб-приложение? Какая разница между традиционным настольным приложением и веб-приложением с точки зрения их рабочей парадигмы, такой как логика запуска и завершения.

Большое спасибо.

Обновление - 1 - 23:14 2011/1/4

Мое настоящее понимание:

Когда поступит какой-либо запрос, URL-адрес, содержащийся в запросе, будет извлечен IIS. Я предполагаю, что IIS должен поддерживать некоторую внутреннюю таблицу, которая отображает URL-адрес в соответствующий физический каталог на диске. В качестве примера возьмем следующий URL:

http://myhost/webapp/page1.aspx

С помощью вышеупомянутой внутренней таблицы IIS найдет файл page1.aspx на диске. И затем этот файл проверяется и находится код кода позади. Затем будет обработан правильный экземпляр класса страницы, и его методы, определенные в файле с кодом, будут вызываться в заранее определенном порядке. Результатом серии вызова метода будет ответ, отправленный клиенту.

Обновление - 2 - 23:32 2011/1/4

URL-адрес - это только идентификатор, который служит индексом в вышеупомянутой внутренней таблице. С помощью этого индекса IIS (или любая технология веб-сервера) может найти физическое местоположение ресурса. Затем с некоторой подсказкой (например, именем расширения файла, например *.aspx) веб-сервер знает, какой обработчик (такой как обработчик ISAPI asp.net) должен использоваться для обработки этого ресурса. Этот выбранный обработчик будет знать, как анализировать и выполнять файл ресурсов.

Таким образом, это также объясняет, почему веб-сервер должен быть расширяемым.

Ответы

Ответ 1

Это зависит от того, какой язык и структура вы используете, но в целом есть несколько точек входа, которые будут привязаны к HTTP-запросам (например, по URL-адресу). Когда сервер получает запрос, соответствующий одному из этих привязок, выполняется связанный код.

Также могут быть различные цепи фильтров и перехватчики, которые выполняются на основе других условий запроса. Вероятно, также будет некоторый код настройки, который сервер выполнит, когда он запустится. В конечном счете, есть еще одна точка входа - главная() функция сервера, но с точки зрения веб-приложения это зависит от привязки запроса.

Изменить в ответ на редактирование вопросов

Я никогда не использовал IIS, но я бы предположил, что нет "таблицы поиска", а вместо этого некоторые правила поиска. Я расскажу вам о вызове страницы .jsp на сервере Apache, который должен быть в основном тем же процессом.

  • Webapp записывается и помещается в файловую систему - например. C:/WWW/mywebapp
  • Веб-сервер получает правило конфигурации, сообщающее ему, что URL-адрес/webapp/должен быть сопоставлен с C:/www/mywebapp
  • Веб-сервер также настроен на распознавание файлов .jsp как сервлетов JSP
  • Веб-сервер получает запрос на /webapp/page 1.jsp, который отправляется в рабочий поток
  • Веб-сервер использует свои правила сопоставления для поиска C:/www/mywebapp/page1.jsp
  • Веб-сервер обертывает код в JSP файле в классе с помощью метода serveRequest(request, response) и компилирует его (если это еще не сделано)
  • Веб-сервер вызывает функцию serveRequest, которая теперь является точкой входа кода пользователя
  • Когда код пользователя завершен, веб-сервер отправляет ответ клиенту, а рабочий поток завершает

Это самая основная система - сервлеты на основе ресурсов (то есть .jsp или .aspx файлы). Правила привязки становятся намного сложнее при использовании таких технологий, как MVC-фреймворки, но основные понятия одинаковы.

Ответ 2

Подобно тому, что упоминается OrangeDog в его ответе, есть много всего, что происходит при обслуживании этих страниц. Прежде чем вы даже попадете в свой код.

Не только в asp.net mvc, но и в asp.net вообще есть разные части, которые вступают в игру, когда вы выполняете запрос.

Есть код, такой как модули, обработчики и т.д., которые снова обрабатывают до того, как он попадет в код страницы. Кроме того, вы можете отобразить одну и ту же страницу, чтобы обрабатывать разные URL-адреса.

Концепция обработчика в asp.net важна, так как существуют различные обработчики, которые отвечают за обработку запросов, которые соответствуют расширениям и/или http-глаголам (get, head, post). Если вы посмотрите на% systemroot%\Microsoft.NET\Framework64\v4.0.30319\Config\web.config, вы можете увидеть раздел. Вы также можете увидеть обработчики в IIS (их можно изменить на x сайт).

Например, HttpForbiddenHandler - это тот, который просто отклоняет запрос. Он сконфигурирован для вызова специальных файлов, таких как источники "*.cs".

Вы можете определить свой собственный обработчик, это не что иное, как класс, реализующий интерфейс IHttpHandler. Таким образом, он имеет 2 метода: ProcessRequest и IsReusable. Это больше похоже на вашу программу cgi, так как реализация в основном представляет собой метод, который создает HTML или любой другой тип вывода на основе информации в запросе.

Страницы Asp.net основываются на этом и имеют множество дополнительных функций, которые облегчают вам разработку страниц. Вы реализуете класс, который наследуется от страницы, и есть два связанных с ним файла кода (.aspx и .cs). То же самое можно сказать и о asp.net mvc, но он структурирован по-разному. Есть гораздо больше, чем это, если вы хотите воспользоваться им, вам нужно будет узнать об этом.

Недостатком этих абстракций является то, что некоторые разработчики теряют контроль над контекстом, который находится в/о базовом. Контекст все тот же, вы создаете приложение, которое принимает запрос и выводит результат. Разница в том, что существует еще много кода, предназначенных для облегчения.

Ответ 3

Что касается более подробного списка жизненного цикла запроса ASP.NET IIS, в HTTPApplication Pipeline существует довольно много этапов. Недавно в Faily появилось хорошее сообщение в блоге, которое, как я думал, было сжато очень кратко и хорошо. Это "События жизненного цикла HTTP-запроса в IIS-конвейере, которые должен знать каждый разработчик ASP.NET" от Suprotim Agarwal.

Для более подробного объяснения вы должны проверить статью MSDN по этому вопросу. Это также будет информация о том, что происходит до этого конвейера.