Что такое SPA в веб-разработке. Одностраничные приложения Назначение одностраничного web портала spa

Роман Липский

Мир программного обеспечения сейчас эволюционирует с огромной скоростью. Всего пару лет назад настольные компьютеры и ноутбуки являлись основными устройствами, под которые была заточена веб-разработка. Сегодня дела обстоят совсем не так.

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

Некоторые считают, что браузерные веб-приложения постепенно вытесняются мобильными приложениями с их огромными клиентскими базами. Но правда в том, что веб-приложения сейчас живы как никогда, и спрос на них сейчас только растёт.

Если вы задумываетесь о разработке веб-приложения для своей компании, вы наверняка уже знаете о том, что существуют два основных подхода к разработке: можно создавать как одностраничные веб-приложения (SPA), так и многостраничные приложения (MPA).

Так же, как и всё в нашей с вами жизни, оба варианта дизайнов имеют свои преимущества и недостатки. Прежде чем приниматься за воплощение идей, нужно принять несколько важных решений.

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

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

Как мы уже упоминали выше, и у SPA, и у MPA есть свои плюсы и минусы. Давайте же разберемся в разнице между двумя типами приложений и постараемся найти правильное решение в области веб-разработки для вашей компании.

Чтобы сделать это, мы попросим директора веб-направления BLAKIT Виталия Озерского дать свои экспертные комментарии по теме. Надеемся, что вместе мы сможем облегчить для вас этот выбор.

Одностраничные приложения

Одностраничные приложения работают в рамках браузера и не требуют перезагрузки страницы или загрузки дополнительных страниц во время использования. Подобные приложения ежедневно используют миллионы юзеров, даже не замечая этого. Самые популярные примеры: GitHub, Gmail, Google Maps и даже Facebook.

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

Одностраничные приложения созданы специально для того, чтобы предоставлять пользователям отличный UX, напоминающий «естественную» среду браузера без перезагрузок страниц, а значит, без задержек при совершении действий.

Типовое одностраничное приложение выглядит как веб-страница, подгружающая и обновляющая контент без перезагрузки с помощью JavaScript. SPA запрашивает разметку страницы и её контент, а затем создает конечный вид страницы непосредственно в браузере. Такого эффекта можно достигнуть благодаря продвинутым фреймворкам JavaScript, таким как AngularJS, Ember.js, Meteor.js, Knockout.js.

ВО: Помимо основных популярных фреймворков разработчики BLAKIT способны также разрабатывать одностраничные приложения при помощи ReactJS.

Основное преимущество React – невысокий порог входа. React довольно прост в использовании; практически любой разработчик, знакомый с HTML, может создавать React-приложения.

Еще одно преимущество – возможность писать приложения под веб и под мобильные платформы, используя единый стек технологий.

Мы используем React вместе с библиотекой Redux, которая позволяет заложить правильную архитектуру и создавать сложные веб-приложения, легко поддающиеся масштабированию.

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

Преимущества одностраничных приложений:
  • SPA характеризуются отличным быстродействием, так как большинство ресурсов, которые они используют (HTML+CSS+Скрипты), загружаются лишь однажды в течение сессии использования приложения. После совершения действий на странице меняются лишь данные.
  • Разработка веб-приложений обычно быстрее и эффективнее. Нет необходимости писать отдельный код для рендера страницы на стороне сервера. Также гораздо легче запустить процесс разработки подобных приложений, потому что писать код можно начинать с файла file://URI, не используя при этом никакой сервер.
  • SPA оптимизированы для Chrome debugging, разработчики могут отслеживать сетевые действия, изучать элементы страниц и данные, с ними ассоциируемые.
  • Если у вас уже есть SPA, будет возможность с тем же бэкендом создать и мобильное приложение.
  • SPA более эффективны в кэшировании данных на локальных носителях. Приложение высылает один запрос, собирает все необходимые данные, и с этого момента способно работать даже в режиме оффлайн.
Недостатки одностраничных приложений:
  • SEO-оптимизация одностраничных приложений, по очевидным причинам, не очень проста. Контент приложений загружается при помощи AJAX (Asynchronous JavaScript and XML) - метода обмена данными и обновления приложения без перезагрузки страницы, в то время как SEO-оптимизация основана на устойчивости контента в каждой отдельно взятой странице. При этом продвижение вашего сайта в поисковиках не невозможно. Многие изменения в SEO можно провести на стороне сервера, а компании вроде Google продолжают придумывать новые решения для того, чтобы облегчить жизнь как владельцам SPA, так и их пользователям.
  • Они довольно долго загружаются, поскольку тяжелые клиентские фреймворки должны сперва загрузиться в браузер.
  • SPA требуют JavaScript в активном режиме в браузерах пользователей. Если кто-то из ваших клиентов вручную отключит использование JavaScript, они не смогут в полной мере воспользоваться вашим приложением. Даже если вы будете кэшировать и обрабатывать ваши страницы на стороне сервера (а это сейчас тоже возможно), вы всё ещё рискуете не доставить пользователям без JS все функции одностраничного приложения в правильном виде.
  • По сравнению с традиционными приложениями, SPA чуть хуже защищены. Благодаря межсайтовому скриптингу (XSS), злоумышленники имеют возможность внедрять дополнительные скрипты на стороне клиента.
  • Некоторые утечки памяти в JavaScript могут привести к падению производительности даже в мощных системах

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

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

Многостраничные приложения

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

Сложность и издержки при разработке MPA выше, также для них требуется многоуровневый дизайн UI. К счастью, сейчас это уже не такая большая проблема, поскольку AJAX позволяет обновлять только определенные части приложения, а не перебрасывать кучу данных между серверами и браузерами.

Преимущества многостраничных приложений:
  • Это наиболее подходящий вариант для пользователей, которым нужен более визуально понятный интерфейс и привычная навигация по приложению. MPA обычно создаются с многоуровневыми меню и другими инструментами навигации.
  • Значительное упрощение SEO. Вы сможете оптимизировать каждую отдельно взятую страницу приложения под нужные вам ключевые слова.
Недостатки многостраничных приложений:
  • Frontend и backend разработка в данном случае объединены очень тесно.
  • Разработка МPA довольно сложна, так как она требует использования фреймворков как на клиентской, так и на серверной стороне. Сроки и издержки разработки, соответственно, не так приятны для многих компаний.
SPA или MPA?

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

Если же вы ориентируетесь на максимальную функциональность в сжатом веб-пространстве, правильным выбором станет одностраничное веб-приложение. А если вам подходит функциональность SPA, но вы даже представить не можете, как вместить весь ваш контент на одну страницу, вам стоит рассмотреть вариант с гибридным сайтом.

Эту форму веб-разработки в статье мы ещё не упоминали. Гибридное приложение нацелено на то, чтобы взять лучшее из двух миров, минимизируя при этом недостатки.

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

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

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

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

ВО: полностью согласен с утверждением про растущую популярность одностраничных приложений. Сейчас SPA-приложения пользуются большим спросом, так как компании постепенно переводят свой софт с десктоп-приложений на приложения, доступные с любого браузера, а не только на ПК с Windows.

В этой статье речь пойдет о Single Page Application (SPA). Будут рассмотрены плюсы и минусы web-приложения построенного по принципам одностраничного сайта (SPA)

Что такое SPA

Single Page Application - сокращенно SPA, в переводе на русский язык означает “Приложение одной страницы”. Другими словами SPA - это web-приложение, размещенное на одной web-странице, которая для обеспечения работы загружает весь необходимый код вместе с загрузкой самой страницы. Приложение такого типа появились сравнительно недавно, с началом эры HTML5 и SPA является типичным представителем приложений на HTML5.

Как мы знаем, HTML5 это нечто иное как HTML + CSS3 + JavaScript + [несколько новых тегов]. Таким образом, SPA - это приложения написанные на языке JavaScript. И, следовательно, немного перефразировав предыдущие определение получаем:

“SPA - это web-приложение, размещенное на одной странице, которая для обеспечения работы загружает все javascript-файлы (модули, виджиты, контролы и т.д.) , а также файлы CSS вместе с загрузкой самой страницы.”

Если приложение достаточно сложное и содержит богатый функционал, как например, система электронного документооборота, то количество файлов со скриптами может достигать нескольких сотен, а то и тысяч. А “…загрузка всех скриптов…” никоим образом не означает, что при загрузке сайта будут загружены сразу все сотни и тысячи файлов со скриптами. Для решения проблемы загрузки большого количества скриптов в SPA призван API под названием AMD . AMD реализует возможность загрузки скриптов по требованию. То есть, если для “главной станицы” одностраничного портала потребовалось 3 скрипта, они будут загружены стразу перед стартом программы. А если пользователь кликнул на другую страницу одностраничного портала, например, “О программе”, то принцип AMD загрузит модуль (скрипт + разметка) только перед тем как перейти на эту страницу.

Получается немного скомкано: “Одна страница.. другая станица, третья страница… одностраничный портал”. Расставим все точки над “Ё”. Страница сайта, на котором размещены все ссылки на все CSS, и ссылки на скрипты, необходимые для работы SPA мы назовем “Web-страница”. Файл с такой странице обычно называется “index.html” (в ASP.NET MVC может быть index.cshtml или index.vbhtml или даже index.aspx) А страницы, которые переключает пользователь внутри одностраничного портала назовем “модули”.

Давайте рассмотрим плюсы и минуты данного подхода. Зачем всё это нужно и почему SPA так популярен?

SPA: Плюсы

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

Далее второй “плюс” - богатый пользовательский интерфейс , так называемый User Experience. Так как web-страница одна, построить богатый, насыщенный пользовательский интерфейс гораздо проще. Проще хранить информацию о сеансе, управлять состояниями представлений (views) и управлять анимацией (в некоторых случаях).

Третий “плюс” - SPA существенно (в разы) сокращает так называемые “хождения по кругу”, то есть загрузку одного и того же контента снова и снова . Если ваш портал (сайт) использует шаблон, то вместе с основным содержанием какой-либо страницы посетитель сайта обязательно загружает разметку шаблона. Да, кэширование данных на данном этапе развития WWW достигло высочайших результатов, но если нечего кэшировать, то и время, и ресурсы на это не тратятся.

SPA: Минусы

Если вы программируете на C#, то единственным минусом SPA является необходимость изучения JavaScript. Во всяком случае, других глобальных проблем мне выяснить не удалось.

Составляющие SPA

Принципы любого фреймворка (о них поговорим позже), который реализует парадигму SPA должны придерживаться следующих понятий и определений:

  • SPA поддерживает клиентскую навигации. Все “хождения” пользователя по модулям-страницам однозначно фиксируются в истории навигации, причем навигация при этом является “глубокой”, то есть если пользователь скопирует и откроет ссылку на внутреннюю модуль-страницу в другом браузере или окне, он попадет на соответствующую страницу.
  • SPA размещается на одной web-странице, значит всё необходимое для работы сайта (портала) скрипты и стили должны быть определены в одном месте проекта - на единственной web-странице.
  • SPA хранит постоянно состояние (важные переменные) работы клиента (клиентского скрипта) в кэше браузера или в Web Storage.
  • SPA загружает все скрипты требующиеся для старта приложения при инициализации web-страницы.
  • SPA постепенно подгружает модули по требованию.
Шаблоны SPA (SPA templates)

Как вы уже наверное догадались, SPA - это абстрактное понятие. Это принцип архитектуры приложения. Давайте поговорим с чего начать при разработке сайта по принципам SPA.

Существует большое количество базовых библиотек (фреймворк - от английского слова framework - “основа, структура, каркас”), которые реализуют принцип Single Page Application. Что дают эти фреймворки:

  • обеспечивают базовые принципы для SPA разработки, минимизируя трудозатраты на решение универсальных задач (смотри раздел “Составляющие SPA);
  • фреймворки созданы сообществом разработчиков, а значит используют опыт создания сайтов множества программистов;
  • фреймворки являются отправной точкой для создания структуры на основе Single Page Application.

Так как я уже много лет работаю на платформе NET, то я буду рассматривать шаблоны Single Page Application на основе ASP.NET. Давайте рассмотрим следующую сравнительную таблицу.

Сравнение возможностей шаблонов SPA

В таблице приведены наиболее распространённые шаблоны для как основа построения Single Page Application приложения. Обратите внимание, синим фоном выделены базовые кирпичики для построения полноценного фреймворка, таких как DurandalJS и HotTowel, которые выделены зеленым цветом.

Итак, следуя данным предоставленных в таблице вы можете создать Single Page Application приложение используя “голый” ASP.NET и KnockoutJS. Однако, реализацию работы с данными (DAL) вам придется писать самостоятельно, впрочем, как и управление навигацией и историей навигации в том числе.

, , Комментарии: 0

В обновлении Web Tools 2012.2 для проектов ASP.NET MVC 4 добавился новый шаблон - Single Page Application (SPA). Этот шаблон предназначен для быстрого построения интерактивных веб-приложений на стороне клиента.

"Single Page Application" (SPA) – это основной термин для веб-приложений, которые загружают одну страницу и затем обновляют ее динамически без загрузки других страниц. Загружена основная страница, и дальше приложение общается с сервером с помощью AJAX-запросов.

AJAX – это не новинка, но сегодня существуют Javascript-библиотеки, которые упрощают разработку и поддержку больших и сложных одностраничных приложений. А HTML5 и CSS3 помогают созданию красивого пользовательского интерфейса.

Рассмотрим пример построения веб-приложения, используя одностраничный шаблон. Построим приложение, которое управляет списком запланированных дел (to-do list).

Создаем новое одностраничное приложение

Для создания приложения потребуется:

  • Visual Studio 2012 или Visual Studio Express 2012 for Web
  • Обновление ASP.NET Web Tools 2012.2, его можно устьановить отсюда.

В главном меню приложения Visual Studio откроем File-> New -> Project . Из предложенных шаблонов проектов выберем ASP.NET MVC 4 Web Application .



Запустим приложение. Откроется форма для авторизации.


Зарегистрируемся.

После входа в приложение создается список дел по умолчанию с двумя элементами и появляется кнопка "Add Todo List" для добавления нового списка.


Архитектура одностраничного приложения

На диаграмме изображены основные блоки приложения.


На стороне сервера ASP.NET MVC генерирует HTML, а также управляет forms-аутентификацией. ASP.NET Web API обрабатывает все запросы, касающиеся списков дел и элементов этих списков. Это – получение, создание, обновление и удаление. Клиент обменивается данными c Web API в формате JSON.

Entity Framework является слоем ORM (object relational mapping), который связывает объектно-ориентированную архитектуру приложения с базой данных. База данных используется локальная (LocalDb), но можно подключить и свою в файле web.config. Обычно для локальной разработки используется локальная база данных, а потом с помощью миграции EF code-first она переносится на SQL server.

Всем привет! В этой статье мы разберемся, что такое SPA в веб-разработке и в чем его плюсы и минусы .

Описание

Возможно, кто-то из вас уже слышал такое сокращение как SPA . Однако не все могут знать, что это такое, поэтому давайте разбираться.

SPA (single page application ) – это веб-приложение, работающее на одной странице. Оно подгружает все необходимые javascript и css файлы при первой загрузке страницы, а затем все общение между клиентом и сервером сводится к минимуму. Т.е. при таком подходе большая часть работы сайта производится на стороне клиента, а если нужно получить данные с сервера, то это обычно делается с помощью JSON .

Такой способ создания сайтов появился относительно недавно, с приходом HTML5 , но уже активно набирает обороты. В принципе, здесь нет ничего удивительного, ведь такое веб-приложение будет работать намного быстрее обычных сайтов, да и разработка не займет много времени. Благо, что сейчас уже есть куча фреймворков, которые позволяют создавать очень сложные сайты такого типа достаточно просто и быстро. На данный момент лучшим фреймворком считается React . У него больше плюсов, чем у конкурентов, а также он прост в изучении и использовании. Если вы хотите побольше узнать о том, как им пользоваться, советую заглянуть . А мы пока перейдем к плюсам SPA .

Плюсы SPA
  • Поддержка большого количества устройств . В отличие от стандартного подхода, SPA приложения работают как на станционарных компьютерах, так и на мобильных устройствах одинаково хорошо. Таким образом, вы можете создать одно приложение и быть уверены, что оно не будет тормозить и будет прекрасно работать даже на не очень мощных устройствах
  • Мощный UX . В приложениях, основанных на таком подходе, намного проще хранить различную информацию, управлять представлением сайта, анимациями. Также, поскольку рабочая страница всего одна, написать красивый пользовательский интерфейс не составит труда
  • Высокая производительность . В обычных сайтах очень часто можно встретить загрузку одного и того же содержимого. Например, шапка сайта, футер, меню и другие элементы, которые не меняются от страницы к странице, тем не менее, каждый раз загружаются с сервера. С использованием SPA подхода такой проблемы просто не будет, т.к. контент будет подгружаться по мере необходимости, что значительно повысит скорость работы приложения

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

Заключение

Итак, сегодня мы рассмотрели, что такое SPA(single page application), в чем его преимущества и недостатки .

Продукты и технологии:

Single-Page Applications (SPA), ASP.NET Web API, Knockout.js, Ember.js, AJAX и HTML5

В статье рассматриваются:

  • создание уровня сервисов и веб-клиента AJAX для приложения-примера;
  • шаблоны MVC и MVVM;
  • связывание с данными;
  • создание веб-клиента с применением Knockout.js;
  • создание веб-клиента с применением Ember.js.

Одностраничные приложения (Single-Page Applications, SPA) - это веб-приложения, которые загружают одну HTML-страницу и динамически обновляют ее при взаимодействии с пользователем.

SPA используют AJAX и HTML5 для создания гибких и адаптивных веб-приложений без постоянных перезагрузок страницы. Однако это означает, что большая часть работы возлагается на клиентскую сторону, а именно на JavaScript-код. Разработчику для традиционной ASP.NET может быть трудно совершить такой кульбит. К счастью, существует множество JavaScript-инфраструктур с открытым исходным кодом, которые облегчают создание SPA.

В этой статье я пошагово пройду процесс создания простого SPA-приложения. Попутно вы ознакомитесь с некоторыми фундаментальными концепциями создания SPA, в том числе с шаблонами Model-View-Controller (MVC) и Model-View-ViewModel (MVVM), связыванием с данными и маршрутизацией (routing).

О приложении-примере

Я создал приложение-пример для операций с простой базой данных по фильмам (рис. 1 ). В крайнем слева столбце страницы отображается список жанров. Выбор жанра приводит к появлению списка соответствующих фильмов. Кнопка Edit рядом с записью позволяет изменять эту запись. После редактирования можно щелкнуть кнопку Save для передачи обновления на сервер или кнопку Cancel для отмены изменений.

Рис. 1. SPA-приложение для базы данных по фильмам

Я создал две версии этого приложения: одна из них использует библиотеку Knockout.js, а другая - библиотеку Ember.js. Эти две библиотеки основаны на разных подходах, поэтому будет весьма поучительно сравнить их. В обоих случаях клиентское приложение не требовало более 150 строк JavaScript-кода. На серверной стороне я задействовал ASP.NET Web API, чтобы обслуживать JSON для клиента. Исходный код обеих версий вы найдете на github.com/MikeWasson/MoviesSPA .

(Примечание Я создавал приложение, используя RC-версию Visual Studio 2013. В RTM-версии некоторые вещи могли измениться, но они не должны повлиять на код.)

Обзор

В традиционном веб-приложении при каждом вызове сервера тот осуществляет рендеринг новой HTML-страницы. Это вызывает обновление страницы в браузере. Если вы когда-нибудь писали приложение Web Forms или PHP, этот жизненный цикл страниц должен быть знаком вам.

В SPA после загрузки первой страницы все взаимодействие с сервером происходит через AJAX-вызовы. Эти AJAX-вызовы возвращают данные (не разметку) - обычно в формате JSON. Приложение использует JSON-данные для динамического обновления страницы без ее перезагрузки. Рис. 2 иллюстрирует разницу между этими двумя подходами.


Рис. 2. Сравнение традиционного жизненного цикла страницы с жизненным циклом в SPA

Одно из преимуществ SPA очевидно: приложения более гибкие и адаптивные, свободные от рваного эффекта перезагрузки страницы и ее рендеринга заново. Другое преимущество может оказаться менее очевидным и касается того, как вы проектируете архитектуру веб-приложения. Отправка данных приложения как JSON обеспечивает разделение между презентационной частью (HTML-разметкой) и прикладной логикой (AJAX-запросы плюс JSON-ответы).

Это разделение упрощает проектирование и развитие каждого уровня. В SPA-приложении с тщательно продуманной архитектурой можно изменять HTML-разметку, не касаясь кода, который реализует прикладную логику (по крайней мере, в идеале). Вы увидите это на практике, когда мы будем обсуждать связывание с данными.

В чистом SPA все UI-взаимодействие происходит на клиентской стороне через JavaScript и CSS. После начальной загрузки страницы сервер действует исключительно как уровень сервисов. Клиенту нужно просто знать, какие HTTP-запросы он должен посылать. Ему не важно, как сервер реализует свою часть.

При такой архитектуре клиент и сервис независимы. Вы могли бы полностью заменить серверную часть, которая выполняет сервис, и, пока вы не изменяете API, вы никак не нарушите работу клиента. Верно и обратное: вы можете заменить все клиентское приложение, не изменяя уровень сервисов. Например, вы могли бы написать родной мобильный клиент, который использует этот сервис.

Создание проекта в Visual Studio

В Visual Studio 2013 есть один тип проекта ASP.NET Web Application. Мастер этого проекта позволяет выбрать ASP.NET-компоненты, которые будут включены в проект. Я начал с шаблона Empty, а затем добавил в проект ASP.NET Web API, установив флажок Web API в разделе Add folders and core references for, как показано на рис. 3 .


Рис. 3. Создание нового ASP.NET-проекта в Visual Studio 2013

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

Обратите внимание на рис. 3 , что Visual Studio 2013 включает шаблон Single Page Application. Этот шаблон устанавливает скелет SPA-приложения, основанный на Knockout.js. Он поддерживает вход с применением базы данных с информацией о членстве в группах или с помощью внешнего провайдера аутентификации. Я не стал использовать этот шаблон в своем приложении, потому что хотел показать более простой пример с нуля. Шаблон SPA - отличный ресурс, особенно если вам нужно добавить аутентификацию в приложение.

Создание уровня сервисов

Я использовал ASP.NET Web API, чтобы создать простой REST API для приложения. Не буду здесь вдаваться в детали Web API - подробности вы можете прочитать по ссылке asp.net/web-api.

Сначала я создал класс Movie, представляющий фильм. Этот класс делает две вещи:

  • сообщает Entity Framework (EF), как создавать таблицы базы данных для хранения информации о фильмах;
  • сообщает Web API, как форматировать полезные данные JSON.

Вы не обязаны использовать одну модель для обеих целей. Например, вам может понадобиться, чтобы схема базы данных отличалась от полезных данных JSON. В этом приложении я ничего не усложняю:

  • namespace MoviesSPA.Models
  • public class Movie
  • public int ID { get; set; }
  • public string Title { get; set; }
  • public int Year { get; set; }
  • public string Genre { get; set; }
  • public string Rating { get; set; }
  • Затем я воспользовался технологией scaffolding в Visual Studio для создания контроллера Web API, который задействует EF в качестве уровня данных. Чтобы применить эту технологию, щелкните правой кнопкой мыши папку Controllers в Solution Explorer и выберите Add / New Scaffolded Item. В мастере Add Scaffold укажите Web API 2 Controller with actions, using Entity Framework, как показано на рис. 4 .


    Рис. 4. Добавление контроллера Web API

    На рис. 5 приведен мастер Add Controller. Я присвоил контроллеру имя MoviesController. Имя имеет значение, так как URI для REST API основываются на имени контроллера. Я также установил флажок Use async controller actions, чтобы задействовать преимущества новой функциональности async в EF 6. Я выбрал класс Movie в качестве модели и указал New data context, чтобы создать новый контекст данных EF.


    Рис. 5. Мастер Add Controller

    Мастер добавляет два файла:

    • MoviesController.cs - определяет контроллер Web API, который реализует REST API для приложения;
    • MovieSPAContext.cs - это в основном склеивающий слой EF, который предоставляет методы для запроса нижележащей базы данных.

    В табл. 1 показан REST API по умолчанию, создаваемый технологией scaffolding.

    Табл. 1. REST API по умолчанию, созданный технологией scaffolding из Web API

    Значения в фигурных скобках являются заменителями для подстановки. Например, чтобы получить фильм с идентификатором, равным 5, URI должен выглядеть так: /api/movies/5.

    Я расширил этот API, добавив метод, который находит все фильмы указанного жанра:

    Клиент указывает жанр в строке запроса URI. Например, чтобы получить все фильмы жанра Drama, клиент посылает GET-запрос на /api/movies?genre=drama. Web API автоматически связывает параметр запроса с параметром genre в методе GetMoviesByGenre.

    Создание веб-клиента

    До сих пор я просто создавал REST API. Если вы отправите GET-запрос на /api/movies?genre=drama, исходный HTTP-ответ будет выглядеть так:

    HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: application/json; charset=utf-8 Date: Tue, 10 Sep 2013 15:20:59 GMT Content-Length: 240 [{"ID":5,"Title":"Forgotten Doors","Year":2009,"Genre":"Drama","Rating":"R"}, {"ID":6,"Title":"Blue Moon June","Year":1998,"Genre":"Drama","Rating":"PG-13"},{"ID":7,"Title":"The Edge of the Sun","Year":1977,"Genre":"Drama","Rating":"PG-13"}]

    Теперь мне нужно написать клиентское приложение, которое делает с этим что-то осмысленное. Базовый рабочий процесс такой:

    • UI инициирует AJAX-запрос;
    • обновляем HTML для отображения полезных данных ответа;
    • обрабатываем AJAX-ошибки.

    Вы могли закодировать все это вручную. Например, вот некоторый jQuery-код, который создает список названий фильмов:

  • $.getJSON(url)
  • .done(function (data) {
  • // При успехе data содержит список фильмов
  • var ul = $("")
  • $.each(data, function (key, item) {
  • // Добавляем элемент в список
  • $("
  • ", { text: item.Title }).appendTo(ul);
  • $("#movies").html(ul);
  • В этом коде есть кое-какие проблемы. Он смешивает прикладную логику с презентационной и тесно связан с вашим HTML. Кроме того, писать его весьма утомительно. Вместо того чтобы сосредоточиться на приложении, вы тратите время на написание обработчиков событий и кода, манипулирующего DOM.

    Решение заключается в том, чтобы использовать JavaScript-инфраструктуру. К счастью, их выбор довольно велик, и эти инфраструктуры имеют открытый исходный код. К некоторым из более популярных инфраструктур относятся Backbone, Angular, Ember, Knockout, Dojo и JavaScriptMVC. Большинство использует вариации шаблонов MVC или MVVM, поэтому будет полезно вкратце рассмотреть эти шаблоны.

    Шаблоны MVC и MVVM

    Корни шаблона MVC уходят в 80-е годы прошлого века и связаны с ранними графическими UI. Цель MVC - разбиение кода на три уровня со своими обязанностями (рис. 6 ). Вот что они делают:

    • модель представляет данные и бизнес-логику предметной области;
    • представление отображает модель;
    • контроллер принимает пользовательский ввод и обновляет модель.

    Рис. 6. Шаблон MVC

    Более современная вариация MVC - шаблон MVVM (рис. 7 ). В шаблоне MVVM:

    • модель по-прежнему представляет данные предметной области;
    • модель представления - это абстрактное отражение представления;
    • представление отображает модель представления и посылает пользовательский ввод модели представления.

    Рис. 7. Шаблон MVVM

    View Model View Model

    В JavaScript-инфраструктуре MVVM представлением является разметка, а моделью представления - код.

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

    Создание веб-клиента с применением Knockout.js

    Для первой версии своего приложения я использовал библиотеку Knockout.js. Knockout следует шаблону MVVM, соединяя представление и модель представления через связывание с данными.

    Чтобы создать привязки данных, вы добавляете к HTML-элементам специальный атрибут data-binding. Например, следующая разметка связывает элемент span со свойством genre в модели представления. Всякий раз, когда изменяется значение genre, Knockout автоматически обновляет HTML:

  • Привязки также могут работать в другом направлении, скажем, если пользователь вводит текст в поле, Knockout обновляет соответствующее свойство в модели представления.

    Удобно, что связывание с данными осуществляется декларативно. Вам не требуется подключать модель представления к элементам HTML-страницы. Просто добавьте атрибут data-binding, и Knockout сделает остальное.

    Я начал с создания HTML-страницы с базовой разметкой без связывания с данными, как показано на рис. 8 .

    Рис. 8. Начальная HTML-разметка

  • Movies SPA
  • TitleYearRating
  • No records found.

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

    Создание модели представления

    Наблюдаемые объекты (observables) занимают центральное место в системе связывания с данными в Knockout. Наблюдаемым является объект, который хранит какое-то значение и может уведомлять подписчиков об изменении этого значения. Следующий код преобразует JSON-представление фильма в эквивалентный объект с наблюдаемыми полями:

  • function movie(data) {
  • var self = this;
  • data = data // {};
  • // Данные из модели
  • self.ID = data.ID;
  • self.Title = ko.observable(data.Title);
  • self.Year = ko.observable(data.Year);
  • self.Rating = ko.observable(data.Rating);
  • self.Genre = ko.observable(data.Genre);
  • На рис. 9 показана начальная реализация модели представления. Эта версия поддерживает только получение списка фильмов. Средства редактирования я добавлю позже. Модель представления содержит наблюдаемые свойства для списка фильмов, строку ошибки и текущий жанр.

    Рис. 9. Модель представления

  • var ViewModel = function () {
  • var self = this;
  • // Наблюдаемые свойства модели представления
  • self.movies = ko.observableArray();
  • self.error = ko.observable();
  • // Жанр, просматриваемый пользователем в данный момент
  • self.genre = ko.observable();
  • // Доступные жанры
  • self.genres = ["Action", "Drama", "Fantasy", "Horror", "Romantic Comedy"];
  • // Добавляем JSON-массив объектов movie
  • // в модель представления
  • function addMovies(data) {
  • var mapped = ko.utils.arrayMap(data, function (item) {
  • return new movie(item);
  • self.movies(mapped);
  • // Обратный вызов для получения ошибок от сервера
  • function onError(error) {
  • self.error("Error: " + error.status + " " + error.statusText);
  • // Получаем список фильмов по жанру
  • // и обновляем модель представления
  • self.getByGenre = function (genre) {
  • self.error(""); // очистка ошибки
  • self.genre(genre);
  • // Инициализируем приложение, получая первый жанр
  • self.getByGenre(self.genres);
  • // Создаем экземпляр модели представления и передаем в Knockout
  • ko.applyBindings(new ViewModel());
  • Заметьте, что фильмы находятся в observableArray. Как и подразумевает его имя, observableArray действует как массив, уведомляющий подписчиков об изменении своего содержимого.

    Функция getByGenre выдает AJAX-запрос серверу на получение списка фильмов, а затем заполняет результатами массив self.movies.

    При использовании REST API одна из самых хитрых частей - обработка асинхронной природы HTTP. jQuery-функция ajax возвращает объект, реализующий Promises API. Вы можете задействовать метод then объекта Promise, чтобы установить обратный вызов, инициируемый, когда AJAX-вызов завершается успешно, и еще один обратный вызов, запускаемый при неудачном AJAX-вызове:

  • app.service.byGenre(genre).then(addMovies, onError);
  • Привязки данных

    Теперь, когда у меня есть модель представления, я могу связать ее с HTML через привязки данных. Для полного списка жанров, который появляется на левой стороне экрана, я использую следующие привязки данных:

  • Атрибут data-bind содержит одно или более объявлений привязок, где каждая привязка имеет форму "привязка: выражение". В этом примере привязка foreach сообщает Knockout перебирать в цикле содержимое массива genres в модели представления. Для каждого элемента в массиве Knockout создает новый элемент

  • . Привязка text в присваивает text в span значение элемента массива, каковой в данном случае является названием жанра.

    На данный момент щелчок названия жанра ни к чему не приводит, поэтому я добавляю привязку click для обработки событий щелчка:

  • Это связывает событие щелчка с функцией getByGenre в модели представления. Здесь нужно было использовать $parent, так как эта привязка осуществляется в контексте foreach. По умолчанию привязки в foreach ссылаются на текущий элемент в цикле.

    Рис. 10. Добавление привязок в таблицу для отображения списка фильмов

    На рис. 10 привязка foreach перебирает в цикле массив объектов movie. Внутри foreach привязки text ссылаются на свойства текущего объекта.

    Привязка visible в элементе

    контролирует, визуализируется ли таблица. Таблица будет скрыта, если массив movies пуст.

    Наконец, вот привязки для сообщения об ошибке и сообщения "No records found" (заметьте, что вы можете помещать в привязку сложные выражения):

    No records found.

    Редактирование записей

    Последняя часть этого приложения дает возможность пользователю редактировать записи в таблице. Для этого необходима следующая функциональность:

    • переключение между режимами просмотра (только текст) и редактирования (элементы управления вводом);
    • передача обновлений на сервер;
    • поддержка отмены изменений и восстановление исходных данных.

    Чтобы отслеживать режим просмотра/редактирования, я добавил булев флаг в объект movie как наблюдаемое свойство:

  • function movie(data) {
  • // Другие свойства опущены
  • self.editing = ko.observable(false);
  • Мне нужно было, чтобы таблица фильмов отображала текст, когда свойство editing равно false, но переключалась на элементы управления вводом, когда оно - true. Для этого я использовал Knockout-привязки if и ifnot, как показано на рис. 11 . Синтаксис "" позволяет включать привязки if и ifnot без их размещения внутри элемента HTML-контейнера.

    Рис. 11. Поддержка редактирования записей о фильмах

  • Привязка value задает значение элемента управления вводом. Это двухсторонняя привязка, поэтому, когда пользователь вводит что-то в текстовое поле или изменяет выбор в раскрывающемся списке, изменение автоматически распространяется на модель представления.

    Я связал обработчики щелчка кнопок с функциями save, cancel и edit в модели представления.

    Функция edit проста. Достаточно установить флаг editing в true:

  • self.edit = function (item) {
  • item.editing(true);
  • Функции save и cancel немного посложнее. Для поддержки отмены мне нужен был какой-то способ кеширования исходного значения при редактировании. К счастью, Knockout упрощает расширение поведения наблюдаемых объектов. В коде на рис. 12 добавляется функция store в класс observable. Вызов функции store из observable придает этому классу две новые функции: revert и commit.

    Рис. 12. Расширение ko.observable функциями revert и commit

  • var self = this;
  • var oldValue = self();
  • read: function () {
  • return self();
  • write: function (value) {
  • oldValue = self();
  • self(value);
  • this.revert = function () {
  • self(oldValue);
  • this.commit = function () {
  • oldValue = self();
  • return this;
  • Теперь я могу вызвать функцию store, чтобы добавить эту функциональность в модель:

  • function movie(data) {
  • // ...
  • // Новый код:
  • self.Title = ko.observable(data.Title).store();
  • self.Year = ko.observable(data.Year).store();
  • self.Rating = ko.observable(data.Rating).store();
  • self.Genre = ko.observable(data.Genre).store();
  • Рис. 13 демонстрирует функции save и cancel в модели представления.

    Рис. 13. Добавление функций save и cancel

  • self.cancel = function (item) {
  • revertChanges(item);
  • item.editing(false);
  • self.save = function (item) {
  • app.service.update(item).then(
  • function () {
  • commitChanges(item);
  • function (error) {
  • onError(error);
  • revertChanges(item);
  • }).always(function () {
  • item.editing(false);
  • function commitChanges(item) {
  • for (var prop in item) {
  • if (item.hasOwnProperty(prop) && item.commit) {
  • item.commit();
  • function revertChanges(item) {
  • for (var prop in item) {
  • if (item.hasOwnProperty(prop) && item.revert) {
  • item.revert();
  • Создание веб-клиента с применением Ember

    Для сравнения я написал другую версию своего приложения, используя библиотеку Ember.js.

    Ember-приложение начинает с таблицы маршрутизации (routing table), которая определяет навигацию пользователя в рамках приложения:

  • window.App = Ember.Application.create();
  • App.Router.map(function () {
  • this.route("about");
  • this.resource("genres", function () {
  • this.route("movies", { path: "/:genre_name" });
  • Первая строка кода создает Ember-приложение. Вызов Router.map создает три маршрута. Каждый маршрут соответствует URI или шаблону URI:

    /#/about /#/genres /#/genres/genre_name

    Для каждого маршрута вы создаете HTML-шаблон, используя библиотеку шаблонов Handlebars.

    В Ember имеется шаблон верхнего уровня для всего приложения. Этот шаблон подвергается рендерингу для каждого маршрута. На рис. 14 показан шаблон application для моего приложения. Как видите, этот шаблон в основном является HTML-кодом, размещаемым в теге script с type="text/x-handlebars". Шаблон содержит специальную разметку Handlebars в двойных фигурных скобках: {{ }}. Эта разметка служит той же цели, что и атрибут data-bind в Knockout. Например, {{#linkTo}} создает ссылку на маршрут.

    Рис. 14. Шаблон Handlebars уровня приложения

  • ko.observable.fn.store = function () {
  • var self = this;
  • var oldValue = self();
  • var observable = ko.computed({
  • read: function () {
  • return self();
  • write: function (value) {
  • oldValue = self();
  • self(value);
  • this.revert = function () {
  • self(oldValue);
  • this.commit = function () {
  • oldValue = self();
  • return this;
  • Movies
  • {{outlet}}
  • 2013 Mike Wasson

  • Теперь допустим, что пользователь переходит к /#/about. Это активирует маршрут about. Ember сначала осуществляет рендеринг шаблона application верхнего уровня, затем шаблона about в {{outlet}} шаблона application. Вот шаблон about:

  • Movies App
  • About this app...
  • На рис. 15 показано, как выполняется рендеринг шаблона about в шаблоне application.


    Рис. 15. Рендеринг шаблона about

    Поскольку у каждого маршрута свой URI, история браузера сохраняется. Пользователь может осуществлять навигацию кнопкой Back, а также обновлять страницу, не теряя контекст или закладку, и перезагружать ту же страницу.

    Контроллеры и модели в Ember

    В Ember каждый маршрут имеет модель и контроллер. Модель содержит данные предметной области. Контроллер действует как прокси для модели и хранит все данные состояния приложения для представления. (Это не совпадает с классическим определением MVC. В некоторых отношениях контроллер больше похож на модель представления.)

    Вот как я определил модель movie:

  • App.Movie = DS.Model.extend({
  • Title: DS.attr(),
  • Genre: DS.attr(),
  • Year: DS.attr(),
  • Rating: DS.attr(),
  • Контроллер наследует от Ember.ObjectController (рис. 16 ).

    Рис. 16. Контроллер Movie наследует от Ember.ObjectController

  • App.MovieController = Ember.ObjectController.extend({
  • isEditing: false,
  • actions: {
  • edit: function () {
  • this.set("isEditing", true);
  • save: function () {
  • this.content.save();
  • this.set("isEditing", false);
  • cancel: function () {
  • this.set("isEditing", false);
  • this.content.rollback();
  • Здесь происходит кое-что интересное. Во-первых, я не указывал модель в классе контроллера. По умолчанию маршрут автоматически устанавливает модель в контроллере. Во-вторых, функции save и cancel используют средства транзакций, встроенные в класс DS.Model. Для отмены изменений просто вызовите функцию rollback модели.

    Ember использует массу соглашений по именованию для подключения различных компонентов. Маршрут genres взаимодействует с GenresController, который выполняет рендеринг шаблона genres. По сути, Ember будет автоматически создавать объект GenresController, если вы его не определили. Однако вы можете переопределять все, что предлагается по умолчанию.

    В своем приложении я сконфигурировал маршрут genres/movies на использование другого контроллера, реализовав точку подключения (hook) renderTemplate. Тем самым несколько маршрутов может использовать один и тот же контроллер (рис. 17 ).

    Рис. 17. Несколько маршрутов могут иметь общий контроллер

  • App.GenresMoviesRoute = Ember.Route.extend({
  • serialize: function (model) {
  • return { genre_name: model.get("name") };
  • renderTemplate: function () {
  • this.render({ controller: "movies" });
  • afterModel: function (genre) {
  • var controller = this.controllerFor("movies");
  • var store = controller.store;
  • return store.findQuery("movie", { genre: genre.get("name") })
  • .then(function (data) {
  • controller.set("model", data);
  • Одна из приятных особенностей Ember в том, что многое можно делать с помощью минимума кода. Мое приложение-пример состоит примерно из 110 строк кода на JavaScript. Эта версия короче, чем версия на основе Knockout, и вдобавок я безо всяких усилий получил поддержку истории браузера. С другой стороны, Ember также является весьма "своенравной" инфраструктурой. Если вы не пишете код в стиле Ember, то скорее всего попадете в неприятности. Так что при выборе инфраструктуры следует принимать во внимание набор функциональности, стиль кодирования и то, насколько общая архитектура инфраструктуры подходит под ваши требования.

    Где узнать больше

    В этой статье я показал, как JavaScript-инфраструктуры упрощают создание SPA. Попутно я рассказал о некоторых общих средствах этих библиотек, в том числе о связывании с данными, маршрутизации и шаблонах MVC и MVVM. Узнать больше о создании SPA с помощью ASP.NET можно по ссылке asp.net/single-page-application .

    Майк Уоссон (Mike Wasson) - программист и технический писатель в Microsoft. Многие годы занимался документированием мультимедийной части Win32 API. В настоящее время пишет о ASP.NET с основным акцентом на Web API. С ним можно связаться по адресу [email protected] .

    Выражаю благодарность за рецензирование статьи эксперту Microsoft Хиньяну Чу (Xinyang Qiu).

  • Save
  • Cancel
  • Edit