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

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

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

РесурсоемкостъViewState

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

В то же самое время превалирующей архитектурой взаимодействия между приложениями через HTTP становится REST (RepresentationalStateTransfer - передача состояния представления), полностью затмевая собой 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 WebForms.