Нашли ошибку или опечатку? Выделите текст и нажмите

Поменять цветовую

гамму сайта?

Поменять
Обновления сайта
и новые разделы

Рекомендовать в Google +1

История развития ASP.NET

84

ASP.NET MVC - это инфраструктура для разработки веб-приложений от Microsoft, которая сочетает в себе эффективность и аккуратность архитектуры "модель-представление-контроллер" (model-view-controller - MVC), новейшие идеи и приемы гибкой разработки, а также все лучшее из существующей платформы ASP.NET. Она представляет собой полномасштабную альтернативу традиционной технологии ASP.NET Web Forms, предоставляя преимущества для всех проектов веб-разработки, кроме самых тривиальных.

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

Развитие ASP.NET на 2002 год

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

Фактически Web Forms - это гигантский уровень абстракции, спроектированный для предоставления классического управляемого событиями графического пользовательского интерфейса через веб-среду. Идея заключалась в том, чтобы веб-разработка выглядела подобно разработке с применением Windows Forms. Разработчики больше не должны были иметь дело с последовательностями независимых запросов и ответов HTTP. Они могли мыслить терминами пользовательского интерфейса, поддерживающего состояние, и в Microsoft появилась возможность переместить армию разработчиков настольных Windows-приложений в новый мир веб-приложений.

Недостатки технологии ASP.NET Web Forms

Разработка с использованием традиционной технологии ASP.NET Web Forms в принципе была замечательной, однако действительность оказалась более сложной.

Ресурсоемкостъ View State

Действительный механизм поддержки состояния между запросами (известный как View State) требует передачи огромных блоков данных между клиентом и сервером. Объем этих данных может достигать сотен килобайт даже в самых скромных веб-приложениях. Эти данные передаются туда и обратно с каждым запросом, приводя к замедлению реакции и увеличивая требования к ширине полосы пропускания сервера.

Жизненный цикл страницы

Механизм подключения событий клиентской стороны к коду обработчиков событий на стороне сервера, являющийся частью жизненного цикла страницы, может быть чрезвычайно сложным и хрупким. Лишь немногим разработчикам удавалось успешно манипулировать иерархией элементов управления во время выполнения, избегая получения ошибок View State или не сталкиваясь с ситуацией, когда некоторые обработчики событий совершенно загадочным образом отказывались функционировать.

Ложное чувство разделения ответственности

Модель отделенного кода ASP.NET Web Forms (Code Behind) предоставляет средства вынесения кода приложения из HTML-разметки в специальный файл отделенного кода. Это отвечает широко принятому принципу разделения логики и представления, но в действительности разработчикам приходилось смешивать код представления (например, работу с деревом элементов управления серверной стороны) и логику приложения (скажем, манипулирование информацией из базы данных) в огромных классах отделенного кода. Конечный результат мог оказаться хрупким и трудным для понимания.

Ограниченный контроль над HTML-разметкой

Серверные элементы управления визуализируют себя в виде HTML-разметки, но не обязательно в виде того кода HTML, который вам нужен. В ранних версиях Web Forms выходная HTML-разметка не соответствовала веб-стандартам или неэффективно использовала каскадные таблицы стилей (Cascading Style Sheets - CSS), а серверные элементы управления генерировали непредсказуемые и сложные значения для идентификаторов, к которым было трудно получать доступ с помощью JavaScript. Эти проблемы были значительно смягчены в последних выпусках Web Forms, но получение ожидаемой HTML-разметки по-прежнему может оказаться затруднительным.

"Дырявая" абстракция

Технология Web Forms пытается скрывать детали, связанные с HTML и HTTP, где только возможно. При попытке реализации специального поведения часто приходится отказываться от абстракции, прибегая к воссозданию механизма обратной отправки событий либо предпринимая противоестественные действия для генерирования желаемой HTML-разметки. Кроме того, вся эта абстракция может превратиться в досадное препятствие для опытных разработчиков веб-приложений.

Низкая тестируемость

Проектировщики Web Forms даже не предполагали, что автоматизированное тестирование станет неотъемлемой частью разработки программного обеспечения. Не удивительно, что построенная ими тесно связанная архитектура совершенно не была приспособлена для модульного тестирования. Интеграционное тестирование также может оказаться сложной задачей.

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

Современное состояние веб-разработки

За рамками решений от Microsoft со времен появления Web Forms технология веб-разработки быстро развивалась в нескольких разных направлениях.

Веб-стандарты и REST

Движение за соблюдение веб-стандартов в последние годы усилилось. Веб-сайты просматриваются огромным множеством разнообразных устройств и браузеров, превышающим все, что было когда-либо ранее, и веб-стандарты (HTML, CSS, JavaScript и т.д.) остаются единственной надеждой на достижение согласованного просмотра содержимого. Современные веб-платформы не могут игнорировать потребности бизнеса и стремление разработчиков к соблюдению веб-стандартов.

Начал массово использоваться стандарт HTML5, и он предоставляет разработчику веб-приложений развитые возможности, позволяющие клиенту выполнять работу, которая ранее входила в исключительную ответственность сервера. Эти новые возможности и рост зрелости таких JavaScript-библиотек, как jQuery, jQuery UI и jQuery Mobile, означает, что стандарты становятся все более важными и формируют необходимую основу для насыщенных веб-приложений.

В то же самое время превалирующей архитектурой взаимодействия между приложениями через HTTP становится REST (Representational State Transfer - передача состояния представления), полностью затмевая собой SOAP (технологию, лежащую в основе первоначального подхода к веб-службам в ASP.NET).

Стандарт REST описывает приложение в терминах ресурсов (URI), представляющих реальные объекты, и стандартных операций (методов HTTP), представляющих доступные операции над этими ресурсами. Например, можно было бы выполнить операцию PUT применительно к http://www.example.com/Products/Pen или операцию DELETE - к http://www.example.com/Customers/Charles_Dickens.

Современные веб-приложения генерируют не только HTML-разметку. Часто они должны также предоставлять данные в форматах JSON или XML различным клиентским технологиям, таким как AJAX, и встроенным приложениям для смартфонов. При использовании REST это происходит естественным образом, устраняя различие между веб-службами и веб-приложениями, но требует определенного подхода к обработке HTTP и URL, который было непросто поддерживать с помощью ASP.NET Web Forms.

Гибкая разработка и разработка через тестирование

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

Двумя примерами являются разработка через тестирование (test-driven development - TDD) и относительно близкая к ней разработка через тестирование поведения (behavior-driven development - BDD).

Идея состоит в таком проектировании программного обеспечения, при котором сначала описываются примеры желаемого поведения (известные как тесты или спецификации), чтобы в любой момент можно было проверить стабильность и корректность работы приложения путем выполнения набора тестов применительно к текущей реализации. Недостатка в инструментах .NET, поддерживающих TDD/BDD, нет, однако они не слишком хорошо работают с Web Forms:

  • Инструменты модульного тестирования позволяют задавать поведение отдельных классов или других небольших блоков кода изолированным образом. Они могут эффективно применяться только к программному обеспечению, которое спроектировано в виде набора независимых модулей, чтобы каждый тест можно было выполнять в изоляции от других. К сожалению, подобным образом могут быть протестированы лишь очень немногие приложения Web Forms.

  • Инструменты автоматизации для пользовательского интерфейса позволяют эмулировать последовательности взаимодействий пользователя с готовым функционирующим экземпляром приложения. Их можно использовать с приложениями Web Forms, но стоит только слегка изменить компоновку страницы, их функционирование нарушится. Без принятия специальных мер приложение Web Forms начинает генерировать совершенно другие структуры и идентификаторы HTML-элементов, делая тестовые наборы неработоспособными.

Сообщество независимых поставщиков программного обеспечения вместе с сообществом открытого кода разработали множество высококачественных инфраструктур модульного тестирования (NUnit и xUnit), инфраструктур имитации (Moq и Rhino Mocks), контейнеров инверсии управления (Ninject и AutoFac), серверов непрерывной интеграции (Cruise Control и TeamCity), инструментов объектно-реляционного отображения (NHibernate и Subsonic) и аналогичных средств. Из-за своего монолитного проектного решения, традиционная технология ASP.NET Web Forms не слишком подходит для таких инструментов и приемов, и поэтому удостаивается не особенно большого внимания со стороны этих проектов.

Ruby on Rails

В 2004 г. платформа Ruby on Rails была тихим и незаметным продуктом с открытым кодом от неизвестного игрока. Однако весьма неожиданно она добилась популярности изменив сами правила веб-разработки. Это было связано не с тем, что платформа Ruby on Rails предложила революционную технологию, а с тем, что она собрала существующие ингредиенты и смешала их настолько великолепным способом, что смогла буквально "пристыдить" существующие на то время платформы.

Платформа Ruby on Rails (или просто Rails, как ее обычно называют) заключала в себе архитектуру MVC. Применение архитектуры MVC и работа в гармонии с протоколом HTTP, внедрение соглашений вместо обязательного конфигурирования и интеграция инструмента объектно-реляционного отображения (object-relational mapping - ORM) в ядро позволило приложениям Rails без особых усилий завоевать относительно высокую популярность.

Это было похоже на открытие того, какой должна быть веб-разработка в целом. Платформа Rails показала, что соблюдение веб-стандартов и соответствие REST не обязательно должны быть трудновыполнимой задачей. Она также продемонстрировала, что гибкая разработка и разработка через тестирование оказываются наиболее успешными, если сама инфраструктура спроектирована для их поддержки. С тех пор остальные представители мира веб-разработки принялись наверстывать упущенное.

Node.js

Еще одна важная тенденция - переход к использованию JavaScript в качестве основного языка программирования. Технология AJAX первой продемонстрировала важность JavaScript, технология jQuery показала, что этот язык может быть мощным и изящным, а JavaScript-механизм с открытым кодом V8 от Google продемонстрировал, что он может быть невероятно быстрым.

В настоящее время JavaScript становится серьезным языком программирования серверной стороны. Он служит языком хранения и запрашивания данных для нескольких нереляционных баз данных, включая CouchDB и Mongo, а также применяется в качестве универсального языка в таких серверных платформах, как Node.js. Платформа Node.js появилась в 2009 г. и быстро завоевала широкое признание. Ниже перечислены ее ключевые инновации.

  • Использование JavaScript. Разработчикам приходится иметь дело с единственным языком - в клиентском коде, внутри логики серверной стороны, в логике запроса данных через CouchDB и т.п.

  • Обеспечение полной асинхронности. Основной API-интерфейс Node.js не предоставляет никаких способов блокирования потока на время ожидания ввода-вывода или любой другой операции. Весь ввод-вывод реализован путем запуска операции, а затем позднего получения обратного вызова, когда ввод-вывод завершен. Это означает, что в Node.js чрезвычайно эффективно используются системные ресурсы и могут обрабатываться десятки тысяч одновременных запросов на один ЦП (Как правило, возможности альтернативных платформ ограничиваются приблизительно сотней одновременных запросов на один ЦП.)

Node.js остается технологией, ориентированной на определенный круг пользователей. Ее самым большим вкладом в разработку веб-приложений стало, как ни странно, предоставление согласованного механизма JavaScript, на основе которого могут быть написаны инструменты разработки. Многие развивающиеся инфраструктуры JavaScript клиентской стороны, такие как AngularJS, имеют хорошую поддержку, основанную на том, что они используют Node.js.

Принятие Node.js для развертывания веб-приложений шло медленнее. Большинство компаний, строящих реальные приложения в ограниченные временные сроки, обычно нуждаются в полномасштабной инфраструктуре, такой как Ruby on Rails и ASP.NET MVC. Платформа Node.js упоминается здесь только для того, чтобы часть проектного решения ASP.NET MVC можно было рассмотреть в контексте отраслевых тенденций. Например, ASP.NET MVC включает в себя асинхронные контроллеры - это способ обработки запросов HTTP с применением неблокирующего ввода-вывода и масштабирования для обработки большего количества запросов на один ЦП.

Пройди тесты