Главная страница   /   1.1. Краткая история веб разработки (ASP.NET MVC 4

ASP.NET MVC 4

ASP.NET MVC 4

Адам Фриман

1.1. Краткая история веб разработки

Для того чтобы понять различные аспекты и дизайнерские задачи ASP.NET MVC, стоит рассмотреть историю веб разработки хотя бы вкратце. На протяжении многих лет платформы для веб разработки от Microsoft демонстрировали возрастающую мощность и, к сожалению, возрастающую сложность. Как показано в таблице 1-1, каждая новая платформа устраняла конкретные недостатки своего предшественника.

Таблица 1-1: Родословная технологий веб разработки от Microsoft
Период Технология Сильные стороны Слабые стороны
Юрский период Common Gateway Interface («общий интерфейс шлюза»), CGI Простота, гибкость и единственный вариант на то время Работает вне веб сервера, таким образом, является ресурсоемким (использует отдельный процесс операционной системы для каждого запроса)
Бронзовый век Microsoft Internet Database Connector, IDC (коннектор баз данных для Интернета) Работает внутри веб сервера Просто оболочка для SQL запросов и шаблонов для форматирования множества результатов
1996 Active Server Pages, ASP (активные серверные страницы) Общая цель Интерпретируется во время выполнения; поддерживает "спагетти-код"
2002/03 ASP.NET Web Forms 1.0/1.1 Скомпилированный; UI, сохраняющий состояние (stateful); обширная инфраструктура; поддерживает объектно-ориентированное программирование Тяжелый по пропускной способности; некрасивый HTML; нетестируемый
2005 ASP.NET Web Forms 2.0
2007 ASP.NET AJAX
2008 ASP.NET Web Forms 3.5
2009 ASP.NET MVC 1.0
2010 ASP.NET MVC 2.0, ASP.NET Web Forms 4.0
2011 ASP.NET MVC 3.0
2012 ASP.NET MVC 4.0, ASP.NET Web Forms 4.5

Примечание

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

Традиционные ASP.NET веб формы

ASP.NET являлся огромным прорывом, когда впервые появился в 2002 году. На рисунке 1-1 показан стек технологий Microsoft, как мы теперь их наблюдаем.

Рисунок 1-1: Стек технологий ASP.NET Web Forms

В Web Froms Microsoft попытался спрятать работу как с HTTP, так и с HTML (которые в то время были незнакомы для многих разработчиков) с помощью моделирования пользовательского интерфейса (UI) в виде иерархии объектов, управляемых со стороны сервера. Каждый элемент управления следил за своим состоянием при всех запросах (с помощью возможности View State), если нужно, обрабатывая себя как HTML и автоматически подключаясь к событиям на стороне клиента (например, к нажатию кнопки) с соответствующим кодом для обработчика событий на серверной стороне. По сути, веб формы представляют собой гигантский слой абстракции, предназначенный для доставки классического событийного графического интерфейса пользователя (GUI) через Интернет.

Идея заключалась в том, чтобы сделать веб разработку наподобие разработки Windows Forms. Разработчикам больше не нужно было бы работать с серией независимых HTTP запросов и ответов; мы смогли бы работать в условиях UI, сохраняющих состояние (stateful). Мы могли бы забыть о Сети и ее природе "несохранения состояния" и вместо этого выстраивать пользовательские интерфейсы при помощи конструктора «drag-and-drop», и представьте себе, или по крайней мере сделайте вид, что все это происходит на сервере.

Что не так с ASP.NET Web Forms?

В принципе, традиционная разработка ASP.NET Web Forms была очень классной, но реальность оказалась более требовательной. Со временем использование веб форм в реальных проектах показало некоторые их недостатки:

  • Вес View State: В результате использования актуального механизма для поддержки состояния между запросами (известного как View State) мы получили большие блоки данных, передаваемые между клиентом и сервером. Эти данные могут достигать сотен килобайт даже для скромных веб приложений, и они идут туда и обратно при каждом запросе, что приводит к увеличению времени отклика и повышению требований к пропускной способности сервера.
  • Жизненный цикл страницы: Механизм для объединения события со стороны клиента с кодом серверного обработчика события – часть жизненного цикла страницы – может быть чрезвычайно сложным и деликатным. Немногие разработчики добились успеха в манипуляциях с элементами управления во время выполнения кода, не получив ошибок View State или не обнаружив, что некоторые обработчики событий таинственным образом не выполнялись.
  • Неправильное разделение задач: Модель выделенного кода (code-behind) ASP.NET предоставляет возможность для того, чтобы вынести код приложения за рамки HTML разметки в отдельный класс выделенного кода. Это широко приветствовалось из-за разделения логики и представления, но, в действительности, разработчики вынуждены смешивать код представления (например, манипуляции с деревом серверных элементов управления) с логикой приложения (например, управлением базами данных) в этих же классах выделенного кода, которые становятся просто чудовищными. Конечный результат может быть недолговечным и непонятным.
  • Ограниченные возможности с HTML: Серверные элементы управления отображают себя как HTML, но не обязательно так, как вы хотите. До версии ASP.NET 4 выходным данным HTML не удавалось соответствовать веб стандартам или хорошо работать с каскадными таблицами стилей (CSS). Также серверные элементы управления генерировали непредсказуемые и сложные значения атрибута ID, к которым трудно получить доступ при помощи JavaScript. Эти проблемы во многом решились в ASP.NET 4 и ASP.NET 4.5, но у вас все еще могут возникнуть сложности в получении того HTML, который вы ожидаете.
  • Абстракции с брешью: Web Forms пытается спрятать HTML и HTTP, где это только возможно. Когда вы пытаетесь реализовать пользовательские механизмы поведения, вы часто можете выпасть из абстракций, которые заставляют вас переделывать механизм обратной передачи событий или выполнять глупые действия, чтобы он сгенерировал желаемый HTML. Кроме того, все эти абстракции могут стать неприятным барьером для компетентных веб разработчиков.
  • Слабая тестируемость: Разработчики ASP.NET не могли предположить, что автоматизированное тестирование станет важным компонентом разработки программного обеспечения. Не удивительно, что жесткая архитектура, которую они разработали, не подходит для модульного тестирования (юнит-тестирования). С интеграционным тестированием также могут возникнуть проблемы.

ASP.NET продолжал развиваться. В версии 2.0 был добавлен набор стандартных компонентов для приложений, и они могут уменьшить объем кода, который вам нужно писать самостоятельно. Релиз AJAX в 2007 году был ответом Microsoft на безумие Web 2.0/AJAX, он поддерживал хорошее взаимодействие со стороной клиента, не усложняя жизнь разработчикам. Все намного улучшилось с релизом ASP.NET 4, который впервые самым серьезным образом принял веб стандарт. Самый последний релиз, ASP.NET 4.5, на самом деле, имеет некоторые черты ASP.NET MVC и применяет их к миру Web Forms, что помогает решить некоторые довольно значимые проблемы, но, несмотря на это, многие внутренние ограничения все же присутствуют.