single page application что это

Как создать SPA на JS и PHP за час

Одностраничные приложения уже давно не в новинку, а скоро вообще станут стандартом веб-разработки. Узнайте, как их создавать, — пока не поздно.

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

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

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

SPA отлично подходит для интернет-магазинов: пользователь может нажать на кнопку «Добавить в корзину» и тут же продолжить смотреть другие товары. Но и для обычных блогов такая технология вполне уместна.

Создать что-то подобное можно и за час. Вы можете посмотреть репозиторий с полным кодом приложения.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Каким должно быть SPA

Чтобы SPA было удобно пользоваться, нужно правильно выстроить обмен данными с сервером. Вот несколько рекомендаций.

Это небольшой список, но он очень важен, потому что иначе ваше SPA станет менее удобным, чем обычный сайт.

Источник

Что такое SPA или одностраничный портал

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

Что такое SPA

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

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

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

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

SPA: Плюсы

SPA: Минусы

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

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

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

Шаблоны SPA (SPA templates)

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

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

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

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

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

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

С другой стороны, вы в праве выбрать Ember или BreezeJS, или даже AngularJS от Google как основу своего сайта или даже как основу своего собственного фреймворка, факт остается фактом, недостающие принципы составляющие концепцию SPA вам придется реализовывать самостоятельно.

Альтернативой предыдущему решению может послужить выбор уже готового полноценного фреймворка (помечены в таблице зеленым фоном). У каждого варианта существуют свои “плюсы” и “минусы”.

Заключение

Примеров приложений построенных по принципам Single Page Application очень много. Одним из самых мощных и общеизвестных является GMail – почтовый сервис компании Google.

Я же хочу привести, как пример, сервис чтения RSS-каналов SilverReader по одной простой причине: этот сервис сделан с использованием фреймворка DurandalJS. И именно этот фреймворк я использовал для построения своего сайта “Что значит имя”.

Источник

Что нужно знать о сайте на SPA SEO-специалисту

В статье руководитель группы оптимизаторов Webit Мария Ефимова рассказывает, что такое SPA-сайты, как их определить, и зачем нужен пререндеринг.

SPA (single page application) – одностраничное приложение. Из названия понятно, что это сайт, состоящий из 1 страницы – index.html.

Примеры сайтов на SPA:

Чтобы понять, чем отличается SPA от обычного сайта, необходимо посмотреть на то, как они работают в сравнении.

На обычном сайте пользователь получает HTML-разметку с сервера, она оформляется с помощью стилей из полученных CSS-файлов, а затем накладываются JS-скрипты которые «оживляют» интерактивные части сайта. При переходе на другую страницу с сервера снова получается HTML и всё происходит заново. Это если совсем упростить то, как работает обычный сайт.

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

После того как файлы получены, JavaScript формирует HTML-разметку прямо в браузере пользователя и накладывает необходимый CSS для оформления. Именно поэтому если открыть исходный код классического SPA, вы не увидите там ничего кроме подключения JS и иногда CSS файлов, потому что весь HTML, который понадобится пользователю, уже лежит внутри JS-файлов.

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

Такой подход сильно ускоряет переходы между страницами, и за счет этого пользователь может использовать сайт, не дожидаясь момента, когда сервер сформирует HTML и отдаст его, потому что тут этого шага просто нет. Причем разработчики SPA пошли еще дальше и научили JS-код подгружать другие необходимые JS-файлы именно тогда, когда они нужны, а не сразу все. Назвали такой процесс lazy-loading.

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

Существуют различные фреймворки для разработки SPA-приложений. Самые популярные:

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

Далее будем рассматривать SPA-сайты на фреймворке Angular.

Для этого необходимо будет открыть консоль разработчика во вкладке с исследуемым сайтом (ctrl shift i).

Консоль разработчика в браузере Яндекс

Для исследования SPA-сайта потребуются вкладки:

Существует несколько способов определить, что сайт построен с помощью фреймворка Angular.

В исходном коде страницы (ctrl shift i) во вкладке Elements присутствует тег с атрибутом ng-version.

Данный тег добавляется самим Ангуляром при компиляции приложения и указывает на версию фреймворка. На данный момент последней версией Angular является версия 11.

Bundling – объединение всех файлов JS-приложения в несколько больших с целью минимизации количества запросов к серверу.

Во вкладке Network загружаются JS-скрипты: main.js, runtime.js, scripts.js, polyfills.js. Названия основных бандлов не меняются в Angular. (Тем не менее, не стоит забывать, что в других фреймворках разработчики сами могут задать аналогичные названия файлов).

Важно! Если в названиях JS-файлов нет хэш-кода (main.*.js, где * – произвольный набор букв и цифр, которые указывают на использование прод-билд), то на сайте не используется AOT-компиляция (про AOT-компиляцию читайте в разделе «На что обратить внимание в консоли разработчика?»).

Источник

Одностраничные приложения: полный гид по разработке

Одностраничные приложения (SPA) успели наделать много шума в интернете. Мы часто встречаем дискуссии о том, зачем использовать их для разработки MVP и как они могут помочь стартапам в достижении бизнес-целей. Мы решили собрать все мнения воедино и создали полный гид по одностраничным приложениям. Вам достаточно прочитать эту статью, чтобы понять SPA, разобраться в их плюсах и минусах и узнать особенностях UX/UI дизайна таких решений. Добро пожаловать!

Время чтения: 8 минут

Что такое одностраничные приложения?

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

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

Лучше один раз увидеть, как работает SPA, чем десять раз прочитать описание. Вспомните свой почтовый ящик — не важно, пользуетесь вы Gmail, Mail или Yandex — это один из популярных примеров одностраничных приложений. Не важно, что вы делаете в приложении: пишите письмо, ищите старый емэйл или чистите папку «Спам», боковая панель с папками, шапка страницы и логотип сайте всегда останутся неизменными. Это и есть SPA!

Примеры одностраничных приложений

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

Gmail, как и многие другие почтовые агенты, является одностраничным приложением.

Google Docs — еще один пример SPA, которые мы используем каждый день.

SPA могут отлично справляться с большим количеством контента – Netflix тому пример.

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

Архитектура ленты новостей Facebook выстроена как одна бесконечная динамичная страница.

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

Даже когда мы выбираем жилье на Airbnb, мы используем SPA.

Большое количество пользователей — не помеха для SPA. Одностраничным приложением Airbnb пользуются 150 https://www.businessofapps.com/data/airbnb-statistics/

миллионов человек по всему миру.

Плюсы одностраничных приложений

Почему крупные компании все чаще и чаще предпочитают одностраничные приложения для своих решений? Мы нашли 3 основные причины:

Давайте нырнем глубже и подробно разберем основные преимущества SPA!

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

Время загрузки страницы напрямую связано с удовлетворенностью пользователей и с прибылью. Например, по данным Google https://www.businessofapps.com/data/airbnb-statistics/

, если время загрузки страницы увеличивается с 1 до 3 секунд, то вероятность того, что пользователи закроют приложение, на 32% выше. Другое исследование https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/

показало, что каждые 0,1 секунды ожидания загрузки страница обходятся Amazon в 1% продаж, что равно миллиардам долларов США. А для поисковика Google дополнительные 0,5 секунды задержки снижают трафик на 20%.

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

2. Возможность переиспользования кода. Если в будущем вы решите расширить свое одностраничное приложение и превратить его в полноценное мобильное приложение, то 20%-30% кода можно будет использовать повторно, вместо того, чтобы писать всё с нуля. Плюс, это поможет вашему стартапу сэкономить время и снизить затраты.

3. Улучшенный UX. При работе с одностраничным приложением пользователям не нужно долго ждать загрузки — после первого раза все работает быстро. Кроме того, когда продукт подгружает данные, пользователи могут видеть состояние загрузки и прикинуть, как долго осталось.

Минусы одностраничных приложений

О дностраничные приложени я хороши, но это не панацея для стартапа. У SPA тоже есть минусы. Вот четыре основных:

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

Проблему индексации поисковыми системами можно решить с помощью Server Side Rendering.

SSR (Server Side Rendering, серверный рендеринг) — способ рендеринга одностраничного приложения на стороне сервера, когда в браузер пользователя отправляется уже полностью отрисованная страница.

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

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

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

3. Кнопка «Назад». Часто говорят, что раз в приложении есть только одна страница, когда пользователь нажимает кнопку «Назад», браузер перекидывает их на ранее открытый веб-сайт, а не на один шаг назад в приложении. И это влияет на опыт взаимодействия с приложением.

Мы ответим на это одним словом: «роутинг». Проблема перехода по кнопкам легко решается еще на этапе разработки.

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

4. Уязвимость приложения. Это минус не только одностраничного решения, но и вообще всех веб-приложений. Они могут быть более уязвимы для программных атак, которые используют межсайтового скриптинга (XSS, от англ. Cross-Site Scripting). С помощью XSS хакеры могут вставлять вредоносный код на страницу и в браузеры пользователей.

Однако эту проблему можно решить, если внимательно отнестись к защите конечных точек данных (data endpoint), поэтому мы рекомендуем уделить особое внимание безопасности данных первичной страницы.

Почему SPA — это тренд 2021?

Еще до 2021 года стало понятно, что скорость = доход. Исследования показывали https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/

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

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

Статистика говорит https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

, что время загрузки страницы напрямую связано с процентом отказов (bounce rate) , когда пользователи уходят без покупки. Например, если время загрузки возрастает с 1 до 5 секунд, то отказы увеличиваются на 90%. А если с 1 до 10 секунд, то шансы потерять клиента повышаются на 123%.

Одностраничные приложения — это удобное решение для разработки MVP в 2021 году. Оно позволяет создать простой и отзывчивый интерфейс, который будет быстро загружаться, при этом не нужно будет тратить миллионы и годы на разработку решения.

Кому подойдет одностраничное приложение?

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

Подведем итоги

Сегодня одностраничные приложения повсюду, и мы пользуемся ими каждый день, не замечая этого. Крупные игроки на рынке приложений — например,Google, Netflix, Pinterest, Facebook и Airbnb, Вконтакте и даже Meduza — используют SPA.

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

С чего начать разработку?

Если вы только выбираете тип приложения, который подойдет для вашего MVP, спросите себя:

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

Что дальше?

SPA подойдут далеко не всем стартапам. Но для тех, кому нужна динамичная и быстрая платформа с небольшими объемами данных, одностраничные приложения — отличный выбор.

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

В Purrweb мы создаем MVP для стартапов с фокусом на UI/UX дизайне за 3-4 месяца. Над нашими проектами работает целая команда: разработчики, UX-дизайнеры и копирайтеры, QA инженеры и проджект-менеджеры.

Мы предлагаем полный цикл разработки и поддержки: от идеи до релиза, и работаем с разными вариантами разработки MVP, включая и одностраничные приложения.

Хотите узнать, подойдет ли вам одностраничное приложение? Заполните заявку сейчас и получите мнение наших экспертов.

Источник

Одностраничные приложения: создание современных адаптивных веб-приложений с помощью ASP.NET

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

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

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

Одностраничные приложения (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, представляющий фильм. Этот класс делает две вещи:

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

Затем я воспользовался технологией 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

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

В табл. 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-ответ будет выглядеть так:

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

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

В этом коде есть кое-какие проблемы. Он смешивает прикладную логику с презентационной и тесно связан с вашим 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

В 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-разметка

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

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

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

На рис. 9 показана начальная реализация модели представления. Эта версия поддерживает только получение списка фильмов. Средства редактирования я добавлю позже. Модель представления содержит наблюдаемые свойства для списка фильмов, строку ошибки и текущий жанр.

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

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

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

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

Привязки данных

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

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

Чтобы отобразить список фильмов, я добавил привязки в таблицу, как показано на рис. 10.

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

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

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