ASP_NET_MVC_4_Framework_s_primerami_na_C_dlya_p

Примечание

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 и автоматически подключаясь к событиям на стороне клиента (например, к нажатию кнопки) с соответствующим кодом для обработчика событий на серверной стороне. По сути, веб формы представляют собой гигантский слой абстракции,

2

предназначенный для доставки классического событийного графического интерфейса пользователя (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 не могли предположить, что автоматизированное тестирование станет важным компонентом разработки программного обеспечения. Не удивительно, что жесткая архитектура, которую они разработали, не

3

подходит для модульного тестирования (юнит-тестирования). С интеграционным тестированием также могут возникнуть проблемы.

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

Веб разработка сегодня

Вне Microsoft технологии веб разработки довольно быстро прогрессирует в нескольких различных направлениях, с тех пор как была впервые выпущена Web Forms. Кроме AJAX появились и другие важные технологии.

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

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

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

Примечание

Вэтой книге мы коснемся HTML5, jQuery и схожих вещей, но мы не будем вдаваться в подробности, потому что эти технологии сами по себе заслуживают особого внимания. Если вы хотите получить более полную информацию, то вы можете найти книги Адама Фримана,

изданные Apress, по этим темам: Pro jQuery, Pro JavaScript for Web Apps (Pro JavaScript для веб приложений) и The Definitive Guide to HTML5 (Полное руководство по HTML5).

Вто же время REST (Representational State Transfer, «передача представлений состояний») стал доминирующей архитектурой для взаимодействия приложений через HTTP, полностью затмевая SOAP (технологию, лежащую в основе оригинального подхода ASP.NET к веб сервисам). REST описывает приложение в условиях ресурсов (URI), представляя реальные объекты и стандартные операции (HTTP методы), отражая доступные операции на этих ресурсах. Например, вы можете использовать PUT с новым http://www.example.com/Products/Lawnmower или DELETE с

http://www.example.com/Customers/Arnold-Smith

Современные веб приложения обслуживают не только HTML. Зачастую они также должны обслуживать данные JSON или XML для различных технологий клиента, включая AJAX,

4

Silverlight, и родных приложений для смартфонов. Это происходит, естественно, с REST, который устраняет исторические различия между веб сервисами и веб приложениями, но требует такого подхода к обработке HTTP и URL, который не так легко поддерживается ASP.NET Web Forms.

Экстремальное программирование и разработка через тестирование (test-driven development, TDD)

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

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

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

Инструменты автоматизированного тестирования пользовательского интерфейса

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

Сообщество создателей .NET приложений с открытым исходным кодом и независимый поставщик программного обеспечения (ISV) создали высококачественные фреймворки для модульного тестирования (NUnit и XUnit), фиктивные фреймворки (Moq и Rhino Mocks), инверсионные контейнеры (Ninject и Autofac), серверы непрерывной интеграции (Cruise Control и TeamCity),

объектно-реляционные мапперы (NHibernate и Subsonic) и тому подобное. Сторонники этих инструментов и методов подали свой голос, создавая публикации и организуя конференции под общим брендом ALT.NET. Традиционная технология ASP.NET Web Forms не поддерживает эти инструменты и методы из-за своего монолитного дизайна, поэтому у этой группы экспертов Web Forms не пользуется особым уважением.

Ruby on Rails

5

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

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

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

Sinatra

Благодаря Rails вскоре многие веб разработчики стали использовать Ruby в качестве основного языка программирования. Но в таком интенсивно развивающемся сообществе это было только вопросом времени, когда появится альтернатива Rails. Самая известная, Sinatra, появилась в 2007 году.

Sinatra отбрасывает почти всю стандартную инфраструктуру Rails (маршрутизацию, контроллеры, представления и т.д.) и просто картирует URL шаблоны для блоков кода Ruby. Посетитель запрашивает URL, вызывающий блок кода Ruby, который будет выполнен, и данные передаются обратно браузеру – вот и все. Это невероятно простой вид веб разработки, но он нашел свою нишу в двух основных направлениях. Во-первых, для поддерживающих REST веб сервисов он просто быстро выполняет свою работу (мы коснемся REST в главе 25). Во-вторых, поскольку Sinatra может быть подключена к широкому спектру HTML шаблонов с открытым исходным кодом и ORM технологиям, она часто используется в качестве основы, на которой собирается пользовательский Web фреймворк в соответствии с архитектурными потребностями любого проекта, который есть под рукой.

Sinatra еще предстоит отвоевать свою долю рынка у серьезных MVC платформ, таких как Rails (или ASP.NET MVC). Мы упоминаем ее здесь лишь для иллюстрации текущих тенденций индустрии веб разработки в сторону упрощения, а также потому что Sinatra выступает в качестве противоположной силы относительно других фреймворков, все более накапливая в себе основной функционал.

Node.js

Другой важной тенденцией является движение в сторону использования JavaScript в качестве основного языка программирования. AJAX впервые показал нам, что JavaScript очень важен, JQuery показал нам, что он может быть мощным и элегантным, а движок Google JavaScript V8 с открытым исходным кодом показал нам, что он может быть невероятно быстрым. Сегодня JavaScript становится серьезным серверным языком программирования. Он служит хранилищем данных и является языком запросов для нескольких нереляционных баз данных, в том числе CouchDB и Mongo. Также он используется в качестве универсального языка на серверных платформах, таких как Node.js.

6

Node.js появился примерно в 2009 году и получил широкое признание очень быстро. Архитектурно он похоже на Синатру в том, что он не применяет MVC паттерн. Это более низкоуровневый способ подключения HTTP запросов к коду. Его основные нововведения заключаются в следующем:

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

Абсолютная асинхронность: Базовый API Node.js просто не блокирует потоки во время ожидания ввода/вывода (I/O) или во время любой другой операции. Все I/O осуществляются с началом операции и затем получением обратного вызова, когда I/O завершается. Это означает, что Node.js делает чрезвычайно эффективным использование системных ресурсов и может обрабатывать десятки тысяч одновременных запросов для CPU (альтернативные платформы, как правило, ограничиваются около сотней одновременных запросов для CPU).

Как и Sinatra, Node.js является нишевой технологией. Обычно большинство бизнес проектов, создавая реальные приложения в ограниченных временных рамках, нуждаются в полных фреймворках, таких как Ruby on Rails и ASP.NET MVC. Node.js упоминается здесь только для того, чтобы мы могли рассмотреть другие современные технологии, а не только ASP.NET MVC. Например, ASP.NET MVC включает в себя асинхронные контроллеры (которые мы опишем в главе 17). Это способ обработки HTTP-запросов с неблокируемым I/O и обработки большего числа запросов для CPU. Вы увидите, что ASP.NET MVC очень хорошо интегрируется со сложным JavaScript кодом, работающим в браузере.

7

Основные преимущества ASP.NET MVC

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

В октябре 2007 года на первой конференции по ALT.NET в Остине, штат Техас, вице-президент Microsoft Скотт Гатри объявил и продемонстрировал новую платформу по разработке MVC, построенную на базовой платформе ASP.NET, явно задуманную как прямой ответ на эволюцию технологий, таких как Rails и как реакцию на критику Web Forms. В следующих разделах описывается, как эта новая платформа преодолела ограничения Web Forms и снова возвеличила

ASP.NET.

Архитектура MVC

Важно различать архитектурный паттерн MVC и ASP.NET MVC Framework. MVC паттерн не является новым, его корни уходят к 1978 году и проекту Smalltalk в Xerox PARC, но он завоевала огромную популярность сегодня в качестве паттерна для веб приложений по следующим причинам:

Взаимодействие пользователя с MVC приложением следует естественному циклу: пользователь совершает действие, в ответ на это приложение меняет свою модель данных и предоставляет пользователю обновленный вид. А затем цикл повторяется. Это очень удобно для веб-приложений, предоставляемых в виде серии HTTP запросов и ответов.

Необходимость веб приложению объединять несколько технологий (например, базы данных, HTML и исполняемый код), как правило, разбивается на множество уровней или слоев. Моделей, которые вытекают из этих комбинаций, естественны для концепции MVC.

ASP.NET MVC Framework реализует MVC паттерн и, тем самым, обеспечивает значительно улучшенное разделение концепций. На самом деле ASP.NET MVC реализует современный вариант MVC паттерна, который особенно хорошо подходит для веб приложений. Вы узнаете больше о теории и практике применения этой архитектуры в главе 3.

Применяя и адаптируя MVC паттерн, ASP.NET MVC Framework сильно конкурирует с Ruby on Rails и аналогичными платформами, и переносит MVC паттерн в основное русло мира .NET. Суммируя опыт и лучшую практику разработчиков, использующих другие платформы, можно сказать, что ASP.NET MVC может предложить даже больше, чем Rails.

Расширяемость

Внутренние компоненты настольного ПК являются независимыми частями, которые взаимодействуют только через стандартные, публично документированные интерфейсы. Вы можете легко вынуть видеокарту или жесткий диск и заменить его другим от другого производителя и будете уверены, что он впишется в слот и будет работать. MVC Framework также построен как ряд независимых компонентов, удовлетворяющих .NET интерфейс или построенных на абстрактном базовом классе, так что вы можете легко заменить компоненты, такие как система маршрутизации, движок для просмотра и так далее другими.

ASP.NET MVC дизайнеры построили его таким образом, чтобы дать вам три варианта выбора для каждого компонента MVC Framework:

8

Использовать реализацию по умолчанию компонента в его нынешнем виде (чего должно быть достаточно для большинства приложений).

Вывести подкласс реализации по умолчанию для настройки ее поведения.

Заменить компонент полностью при помощи новой реализации интерфейса или абстрактного базового класса.

Это похоже на модель еще из ASP.NET 2.0, но давайте пойдем еще дальше – прямо в сердце MVC Framework. Вы узнаете все о различных компонентах, как и почему вы, возможно, захотите настроить или заменить каждый из них, начиная с главы 12.

Жесткий контроль над HTML и HTTP

ASP.NET MVC признает важность получения чистой, соответствующей стандартам разметки. Его встроенные методы HTML помощника предоставляют соответствующие стандартам выходные данные, но есть и более значительные философские изменений по сравнению с Web Forms. Вместо того чтобы плодить огромные участки HTML, котором нам сложно управлять, MVC Framework рекомендует вам выработать простой, элегантный стиль разметки с помощью CSS.

Конечно, если вы хотите использовать некоторые готовые виджеты для сложных элементов пользовательского интерфейса, такие как выбор даты или каскадное меню, то вам стоит знать, что подход ASP.NET MVC к разметке упрощает использование лучших в своем роде UI библиотек, таких как JQuery UI или библиотеки Yahoo YUI. Разработчики JavaScript будут рады узнать, что ASP.NET MVC так хорошо сработался с популярной библиотеки JQuery, что Microsoft сделал JQuery встроенной частью шаблона проектов ASP.NET MVC и даже позволяет напрямую ссылаться на .js файл jQuery на собственных CDN серверах Microsoft.

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

Как Ruby on Rails, ASP.NET MVC работает в гармонии с HTTP. Вы полностью контролируете запросы, проходящие между браузером и сервером, поэтому вы можете подогнать настройки под себя, на сколько вам это нравится. AJAX сделан просто, и нет никакого автоматического обратного вмешательства в состояния на стороне клиента. Любой разработчик, который в первую очередь фокусируется на веб программировании, почти наверняка посчитает это освобождением и будет наслаждаться рабочим процессом.

Тестируемость

Архитектура MVC дает вам отличную возможность создавать ваше приложение таким, чтобы его можно было легко сопровождать и тестировать, потому что вы, естественно, захотите разделить логические блоки приложения по независимым частям программного обеспечения. Тем не менее, создатели ASP.NET MVC на этом не остановились. Для поддержки модульного тестирования они приняли компоненто-ориентированный дизайн фреймворка и убедились, что каждая отдельная часть построена так, чтобы отвечать требованиям модульного тестирования.

Они добавили мастера (визарды) Visual Studio для создания начальных проектов модульного тестирования от вашего имени, которые интегрированы с инструментами модульного тестирования с открытым исходным кодом, такими как NUnit и XUnit, а также собственным

9

MSTest Microsoft. Даже если вы никогда не писали модульных тестов, вам будет легко в этом разобраться.

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

Тестируемость – это не только вопрос модульного тестирования. ASP.NET MVC приложения также хорошо работают с инструментами автоматического тестирования. Вы можете написать тестовые скрипты, которые имитируют взаимодействие с пользователем, без необходимости гадать, какие структуры HTML элементов, CSS классы или ID будет генерировать фреймворк, и вам не придется беспокоиться о структуре, если она вдруг неожиданно изменится.

Мощная система маршрутизации (роутинга)

Стиль ссылок изменился, поскольку технология веб приложений улучшилась. Такие ссылки, как эта:

/App_v2/User/Page.aspx?action=show%20prop&prop_id=82742

можно встретить довольно редко. Теперь они заменены более простым и чистым форматом:

/to-rent/chicago/2303-silver-street

Есть несколько веских причин для заботы о структуре URL. Во-первых, поисковые системы придают значительный вес ключевым словам, находящимся в URL. Поиск "аренда в Чикаго" (rent in Chicago) имеет гораздо больше шансов с простым URL. Во-вторых, многим пользователям Интернета теперь хватит навыков и знаний, чтобы понять URL, и оценить возможности навигации, набрав его в адресной строке своего браузера. В-третьих, когда кто-то понимает структуру URL, он, скорее всего, будет ссылаться именно на него, поделится этой ссылкой с

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

В более ранних фреймворках было сложно реализовать чистые ссылки, но ASP.NET MVC использует возможность System.Web.Routing, которая по умолчанию создает чистые URL-адреса. Теперь вы можете контролировать схему ссылок и ее связь и отношение к приложению, то есть вы свободны в создании шаблона URL-адресов, которые являются значимыми и полезными для пользователей, без необходимости соответствовать предопределенному шаблону. И, конечно, это означает, что вы можете легко определить современную URL схему в стиле REST, если захотите. Более подробную информацию о маршрутизации и лучших способах создания чистых URL вы найдете в главах 13 и 14.

Возможность разрабатывать в лучших сегментах платформы ASP.NET

Существующая платформа Microsoft ASP.NET предоставляет зрелый, хорошо зарекомендовавший себя набор компонентов и средства для разработки эффективных и действенных веб приложений.

Во-первых, и что наиболее очевидно, поскольку ASP.NET MVC основан на. NET платформе, у вас есть возможность писать код на любом .NET языке и иметь доступ к тем же API функциям, не

10