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