Функционирование веб-приложений существенно отличается от функционирования других типов приложений. Веб-приложения работают в рамках протокола HTTP/HTTPS в режиме запрос ответ. Давайте рассмотрим классический цикл обработки одного запроса.
Как видно, при указанном взаимодействии присутствуют клиент и сервер. Основная последовательность действий выглядит так: браузер генерирует запрос и отправляет его на сервер, на стороне сервера этот запрос обрабатывается и веб-сервер определяет, к какому веб-приложению относится этот запрос, после чего запускается исполнение программного кода, формирование ответа для клиента и отправка его клиенту, клиент после получения ответа отображает его пользователю. Для разработчиков веб-приложений в этой цепочке наиболее важен момент между начальной обработкой запроса и формированием ответа для клиента – исполнение программного кода. В самом простейшем случае этот программный код представляет из себя небольшую программу, которая считывает с жесткого диска файлы и передает их далее на обработку. Такие веб-сайты называются статическими, поскольку не содержат никакой программной логики по обработке запроса, и просто передают содержимое файлов клиенту. Функциональности таких приложений очень часто оказывается недостаточно, поэтому используется другой подход. В момент запуска приложения запускается не программный код считывания данных с жесткого диска, а некоторый программный код, содержащий логику приложения. Например, там может содержаться логика по обращению к СУБД, формированию сложных представлений, созданию специализированных форм и т.д.
Приведенный выше алгоритм функционирования веб-приложений содержит две важные проблемы, которые сказываются на процессе разработки таких приложений:
Давайте рассмотрим каждую проблему более подробно.
Во-первых, программный код веб-приложений всегда исполняется на сервере. Несмотря на то, что инициатором запуска программного кода является клиент, программный код никогда не запускается на стороне клиента. Исключения составляют такие инструменты как сценарии JavaScript, объекты ActiveX, приложения RIA (Silverlight, Flash). Однако, несмотря на это основной программный код исполняется все-таки на стороне сервера. Это означает, что каждое действие пользователя инициирует HTTP-запрос к серверу, на который сервер должен ответить корректным HTTP-ответом. Такое взаимодействие составляет основу функционирования веб-приложений. Такой способ сильно отличается от сценария функционирования настольного приложения, когда программный код приложения загружен в оперативную память того компьютера, где работает пользователь. В случае с разработкой веб-приложений следует учитывать этот момент.
Во-вторых, веб-сервер обычно не сохраняет состояния. Это означает, что веб-сервер уничтожает все данные о клиенте всякий раз, когда обработка запроса завершена. Такое поведение для веб-сервера вполне оправдано – поскольку веб-сервер может обрабатывать большое количество пользователей одновременно, то если он не будет удалять данные после каждого запроса, то в какой-то момент времени у него закончится свободная память и он совсем не сможет выполнять свои функции. Однако, с другой стороны для работы приложения очень часто требуется сохранять состояние и возвращаться к нему при очередном запросе. Например, пользователь может заполнить форму, содержащую набор полей и захотеть вернуться к редактированию этой формы позже. Другой пример – авторизация на веб-сайте: после того, как пользователь ввел свое имя и пароль, он должен взаимодействовать с приложением как авторизированный пользователь, при этом не вводить каждый раз свои данные.
Эти две основные проблемы вызваны спецификой функционирования веб-приложений и не могут быть решены на уровне веб-сервера. Поэтому они ложатся на плечи разработчика веб-приложений и той платформы, на основе которой это приложение работает. К счастью, платформа Microsoft ASP.NET содержит ряд различных инструментов, которые позволяют успешно решить эти проблемы. На протяжении следующих лекций мы рассмотрим эти инструменты и научимся строить веб-приложения.
Веб-приложения работают на основе протокола HTTP/HTTPS в режиме "запрос-ответ". С этим связано две основные проблемы – весь программный код веб-приложения исполняется на стороне сервера и веб-сервер при этом не хранит состояния. Эти проблемы могут создавать массу неудобств разработчику и решаются обычно силами разработчика веб-приложений и инструментами платформы разработки. Платформа Microsoft ASP.NET содержит все необходимые инструменты, которые позволяют справиться с указанными проблемами.
ASP.NET Web Forms – это механизм, который работает на базе общей среды исполнения ASP.NET и встроен в поставку ASP.NET начиная с самой первой версии. Механизм веб-форм предполагает построение веб-приложений аналогично тому, как мы привыкли их строить в случае с настольными приложениями. Этот механизм пытается исключить различия между веб-приложениями и настольными приложениями, сделав процесс их построения максимально похожим.
Как мы помним, результат работы веб-приложения – это код HTML, который передается клиенту. Обычно HTML-код страницы веб-приложения содержит различные элементы, которые позволяют управлять процессом работы приложения – например, кнопки, поля ввода, переключатели и т.д. Эти элементы управления можно описать на языке HTML. Например, можно создать небольшую форму на языке HTML, как показано ниже.
При попытке открыть подобный HTML-код в браузере можно увидеть следующую несложную форму.
После того, как в поля ввода ввести какие-либо значения и нажать кнопку отправки информации на сервер, браузером будет сгенерирован HTTP-запрос методом POST, в котором тело запроса будет содержать строку вида:
FirstName=IvanLastName=PetrovCS=on
Как видно, в теле запроса содержатся параметры, которые присутствуют на форме – строки и флажки. Несмотря на тип каждого параметра, все они передаются в виде строкового значения. Например, состояние флажка "C#" передается как "CS=ON". Поэтому для считывания состояния этого элемента управления можно использовать следующий код.
Из этого примера видно, что значения элементов на форме нетипизированны. Это означает, что какой бы смысл не содержался в элементе управления (строка, число, флаг, переключатель и т.д.), при обработке этого элемента мы всегда вынуждены иметь дело со строками.
Подход ASP.NET Web Forms для решения этой проблемы предлагает ввести понятие элемента управления в структуру страницы. Элемент управления ASP.NET Web Forms – это объект .NET Framework, который является наследником базового класса Control и который реализует в себе логику какого-либо элемента на странице. При этом этот объект берет на себя обязательства по генерации собственного HTML-представления, обработке параметров HTTP-запроса и другие операции, связанные с этим элементом. Таким образом, можно сказать, что элемент управления ASP.NET Web Forms является аналогом элемента управления настольного приложения. Платформа ASP.NET уже содержит ряд стандартных, наиболее часто используемых элементов управления, таких как кнопка, поле ввода, переключатели и т.д. Предыдущий пример можно переписать следующим образом.
Как видно, вместо стандартного описания элементов HTML используются объекты ASP.NET. Эти объекты отличает наличие префикса "asp" в названии тега, а также атрибута "runat="server"", который говорит среде исполнения о том, что этот тег является серверным элементом управления. При обращении к веб-форме с таким описанием мы получим аналогичное представление.
Отличием такой формы от приведенной ранее состоит в том, что в этом случае каждый элемент управления является объектом .NET Framework, который содержит все необходимые типизированные свойства. Поэтому в данном случае состояние флажка можно получить, используя следующий код.
Как видно из этого примера, у элемента управления CheckBox доступно свойство Checked, которое имеет тип bool. В данном случае не требуется всегда работать со строками, поскольку каждый элемент управления содержит типизированные свойства.
ASP.NET Web Forms содержит уже достаточно большое количество различных элементов управления, которые содержат готовую логику. Эти элементы управления можно использовать в своих приложениях. Однако, если функциональных возможностей этих элементов управления окажется недостаточно, то есть возможность разработать собственный элемент управления, который будет содержать всю необходимую логику.
Для отправки данных на сервере в рамках веб-формы используется механизм обратного вызова (Postback). При обратном вызове выполняется обращение к веб-серверу в виде HTTP-запроса методом POST, в составе которого передаются данные серверу. Этот механизм мы рассмотрим далее, при подробном обсуждении модели ASP.NET Web Forms.
Таким образом, платформа ASP.NET Web Forms является еще одним уровнем абстракции по форм HTML и позволяет строить веб-приложения в том же стиле, что и настольные приложения.
ASP.NET Web Forms – это инструментарий, который встроен в общую платформу ASP.NET и позволяет создать собственные веб-формы в составе веб-приложения. Идеология ASP.NET Web Forms строится на основе концепции элементов управления. Элемент управления ASP.NET Web Forms – это объект .NET Framework, который отвечает за обработку входящих параметров, генерацию собственного HTML-представления и т.д. Таким образом, механизм ASP.NET Web Forms позволяет подойти к разработке веб-приложения по аналогии с разработкой настольного приложения.
Технология ASP.NET MVC Framework – это сравнительно новый инструмент, который появился в составе Microsoft ASP.NET. Многие годы развития Microsoft ASP.NET эту платформу связывали именно с ASP.NET Web Forms. Однако, несмотря на все преимущества этого инструмента, он обладает рядом недостатков, с которыми разработчиками постоянно приходилось мириться:
ViewState при определении сложной логики страницы;Эти и другие проблемы заставили разработчиков задуматься над вопросами разработки приложений для платформы ASP.NET и предложить обновленный, более гибкий инструмент – ASP.NET MVC Framework.
ASP.NET MVC Framework – это технология, которая работает в рамках общей среды исполнения приложений ASP.NET. Главной идеей, заложенной в ASP.NET MVC Framework является использование шаблона проектирования "Model-View-Controller". Согласно этому шаблону весь программный код приложения разделяется на три составляющих:
модель (model) |
содержит бизнес-логику приложения; |
представление (view) |
содержит программный код генерации представления (HTML-кода); |
контроллер (controller) |
содержит программный код обработки пользовательского ввода, вызов нужных методов модели и создание объекта представления. |
Общий процесс обработки запроса выглядит следующим образом: при поступлении входящего запроса среда ASP.NET MVC Framework согласно таблице маршрутизации определяет какой контроллер и действие контроллера будут обрабатывать этот запрос; после этого контроллер обращается к модели для выполнения соответствующих бизнес-операций и, если это необходимо, получения данных; после этого контроллер создает представление и передает туда все необходимые данные; представление, если это необходимо, также может обратиться к модели для получения данных; после выполнения всех этих операций, представление генерирует HTML-код для пользователя и передает его клиенту. Весь этот процесс можно представить схематически следующим образом.
Таким образом, модель обработки запроса в ASP.NET MVC Framework существенно отличается от традиционной модели, заложенной в ASP.NET Web Forms.
Во-первых, в ASP.NET MVC Framework на уровне платформы заложена идеология разделения кода. Аналогичные шаблоны проектирования можно использовать и в ASP.NET Web Forms, однако, в ASP.NET MVC Framework они доступны на уровне идеи самой платформы.
Во-вторых, в ASP.NET MVC Framework отсутствует понятие элемента управления. Поскольку модель обработки запроса в ASP.NET MVC Framework достаточно гибкая, то ее составляющие могут подменяться. Например, можно подменить стандартный механизм генерации представления и использовать вместо стандартных ASPX-страниц, например, механизм Brail или что-то еще. По этой причине элементы управления были исключены из состава функциональных строительных блоков в ASP.NET MVC Framework. Исключение составляет лишь возможность сгенерировать HTML-код элементов управления для обратной совместимости с ASP.NET Web Forms.
В ASP.NET MVC Framework вместо вставки элементов управления на страницу, требуется собственноручно писать код HTML, что, несомненно, дает полный контроль над получаемым, в результате генерации страницы, HTML-кодом. Однако, для наиболее часто используемых HTML-конструкций существуют специальные классы, которые называют Helpers, которые позволяют генерировать наиболее востребованный код. Например, код для поля ввода можно сгенерировать следующим образом:
Другим отличием ASP.NET MVC Framework является то, что вся обработка пользовательского ввода осуществляется в рамках контроллера. Это означает, что представление и модель не должны заниматься обработкой данных, специфичных для HTTP-запроса и HTTP-ответа.
Наконец, платформа ASP.NET MVC Framework подталкивает разработчика к тому, чтобы писать тестируемый программный код, т.е. такой программный код, который легко поддается тестированию с помощью модульных тестов.
Следует отметить, что проект ASP.NET MVC Framework разрабатывается командой в составе Microsoft, но при этом является проектом с открытым исходным кодом. Это означает, что любой желающий может получить доступ к исходным кодам проекта ASP.NET MVC Framework. Также существует проект сообщества разработчиков, который называется MVC Contrib . Эта библиотека содержит набор улучшений для основной функциональности ASP.NET MVC Framework.
Платформа ASP.NET MVC Framework работает в рамках общей среды исполнения приложений ASP.NET и является альтернативой ASP.NET Web Forms. В отличие от ASP.NET Web Forms, платформа ASP.NET MVC Framework позволяет разрабатывать более гибкие приложения. В ASP.NET MVC Framework весь программный код делится на модель (model), представление (view) и контроллер (controller).
Появление технологии ASP.NET MVC Framework и ее успех на рынке породило множество предположений о том, что Microsoft планирует отказаться от дальнейшего развития ASP.NET Web Forms. Однако при более детальном рассмотрении каждого из подходов становится понятно, что каждый из подходов обладает рядом преимуществ и каждую из этих технологий хорошо использовать в конкретных ситуациях. Давайте более подробно рассмотрим преимущества и недостатки каждой из платформ.
Приложения на базе ASP.NET Web Forms как правило состоят из набора форм с состояниями. Каждая форма состоит из набора элементов управления, которые реализуют готовую функциональность. Это зачастую очень удобно, когда требуется создавать набор различных форм по аналогии с настольным приложением и при этом не заботиться о таких механизмах как сохранение состояния или реализация сложных элементов управления (например, таблиц, календарей и т.д.).
Кроме того, наличие множества готовых элементов управления и механизмов позволяет достаточно быстро, несколькими движениями мыши построить примерный пользовательский интерфейс. Такой подход очень удобно использовать при построении прототипов приложений, когда большую роль играет не гибкая и стройная архитектура приложения, а скорость получения работающего прототипа.
Также не стоит забывать о том, что ASP.NET Web Forms исторически появилась намного раньше, чем ASP.NET MVC Framework. А это означает, что за время существования ASP.NET Web Forms появилось огромное количество решений от сторонних разработчиков, как платных, так и бесплатных. Это позволяет с достаточно большой вероятностью говорить о том, что в случае, если потребуется какое-либо нестандартное поведение в рамках приложения ASP.NET, то в случае использования ASP.NET Web Forms его можно будет найти среди разработок других производителей.
Однако, ASP.NET Web Forms обладает недостатками. К основным недостаткам можно отнести то, что модель исполнения ASP.NET Web Forms в некоторой степени изолирует разработчика от "родного" для веб-приложений процесса, модели "запрос-ответ". Вместо этого предлагается рассматривать разработку веб-приложения с позиции разработки настольного приложения. Иногда это вносит ряд неудобств и создает излишние накладные расходы. Кроме того, ASP.NET Web Forms не позволяет получить полный контроль над получаемым в итоге HTML-кодом. Поскольку большую часть HTML-кода генерируют сами элементы управления, то разработчику остается надеяться на то, что генерируемый ими HTML-код будет построен корректно. Наконец, ASP.NET Web Forms не стимулирует разработчиков разделять код. Многие приложения на базе ASP.NET Web Forms внутри программного кода самой страницы (по сути, представления) содержат код по обработке запроса, код бизнес-логики и т.д.
Приложения на базе ASP.NET MVC Framework обычно лишены этих недостатков. Весь программный код приложений на платформе ASP.NET MVC Framework обычно разделяется на бизнес-логику, представление и обработку пользовательского ввода. Это придает архитектуре дополнительную гибкость и делает более простым дальнейшее обслуживание и развитие веб-приложения.
Более того, при разработке веб-приложений на базе ASP.NET MVC Framework разработчики более приближены к "родному" процессу обработки запроса, к модели "запрос-ответ". В ASP.NET MVC Framework нет абстрагирования от этого процесса, что в какой-то степени делает разработку приложения более прозрачной.
За счет того, что в ASP.NET MVC Framework отсутствует понятие элемента управления, становится возможным говорить о том, что разработчик веб-приложения имеет действительно полный контроль над разметкой HTML, которая получается в результате работы приложения. Веб-разработчик более не зависит от разработчиков элементов управления и может сам определять, как именно должен строиться HTML-код в его приложении.
Однако, несмотря на все эти преимущества платформы ASP.NET MVC Framework, она обладает и рядом недостатков. Во-первых, разбиение приложения на несколько составляющих (модель, контроллер, представление), несомненно, дает выигрыш в гибкости архитектуры приложения, но требует больше времени на разработку приложения. В некоторых случаях необходимо максимально быстро разработать приложение, а не заботиться об архитектурных изысках. Например, к таким случаям относится создание прототипа какой-либо функциональности.
Отсутствие элементов управления тоже можно отнести к недостаткам, поскольку в этом случае разработчик веб-приложения должен собственноручно разрабатывать ту функциональность, которая ранее была заложена в логику элемента управления.
Таким образом, можно сделать вывод, что каждая из платформ хорошо подходит для своего круга задач. Можно резюмировать вышесказанное следующим образом. Платформа ASP.NET Web Forms наиболее удачно подходит для следующих случаев:
С другой стороны, платформа ASP.NET MVC Framework наиболее удачно подходит для других случаев:
С появлением ASP.NET MVC Framework у разработчика встал выбор – что использовать ASP.NET MVC Framework или ASP.NET Web Forms. Общий ответ на этот вопрос заключается в том, что обе платформы на сегодняшний день активно развиваются, а что выбрать из этих двух вариантов зависит от того, в каких условиях находится разработчик и какого типа проект ему предстоит разрабатывать.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.