Рекомендуемый способ разработки приложения AJAX

Question

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

Мой вопрос: если вам нужно создать приложение AJAX, какой из двух подходов вы бы предпочли:

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

2. Полноценное приложение js, например, созданное с Cappuccino.Sproutcore или Backbone.js, где клиентская сторона толстая, и реализует реализацию MVC на стороне клиента, которая также обрабатывает модель, управляет логикой и просматривает взаимодействия.Серверная сторона в этом случае играет роль набора служб JSON / XML, с которыми клиент обменивается данными.Недостатком в этом случае является то, что шаблоны представлений должны быть загружены в начале, когда начальное приложение загружается, чтобы javascript мог размещать разметку на основе данных.Преимуществами являются уменьшенный вес ответа сервера, а также лучший контроль в клиенте, что позволяет применять такие вещи, как привязка модели представления.

3. Несколько смешанный подход междуте два.

Я предпочитаю второй вариант, который является нормальным, поскольку я прихожу из похожей среды, но в этой среде меня больше всего волнуют такие вопросы, как маршрутизация URL-адресов (или глубокие ссылки привызовите его во Flash), управление состоянием, модульность и макет представления (когда загружаются шаблоны разметки представления? Должны ли быть определенные конечные точки сервера, которые предоставляют эти шаблоны при вызове, чтобы данные шаблона не загружались в начале?)

Прокомментируйте, пожалуйста

Answer 1

Я предпочитаю # 2 сам, но копаю яваскрипт :)

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

Что касается шаблонов на стороне клиента, то лучше всего, когда у выбранной вами серверной платформы есть история (например, конвейер ресурсов rails 3.1 или плагин jammit для pre 3.1). Если вы используете рельсы, я могу дать больше информации, но если вы не первым делом, я хотел бы найти систему управления активами, которая бы справлялась с этим из коробки.

Мой запасной вариант - просто вставлять шаблоны в шаблоны на стороне сервера внутри тега скрипта, например

<script type='text/html' id='foo-template'></script>

Чтобы получить строку позже, вы можете сделать что-то вроде этого (синтаксис jquery)

var template = $('#foo-template').html();

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

<%= render :partial => 'templates/foo.html.erb' %>

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

Answer 2

Я бы порекомендовал второй подход. Второй подход (подход с использованием тонкого сервера для толстого клиента), с которым вы уже знакомы, является предпочтительным подходом для все большего числа современных разработчиков, поскольку рендеринг и управление виджетами осуществляется на клиенте, что позволяет сэкономить вычислительные и пропускные расходы на сервере. Кроме того, если у вас есть сложное управление виджетами, то использование серверного кода для виджетов может стать все более сложным и неуправляемым. Указанный вами недостаток:

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

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

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

Кроме того, мощные и зрелые библиотеки виджетов на стороне сервера доступны только для бэкэндов Java (например, vaadin). Если вы работаете с php, python или ruby ​​backend, то написание собственной инфраструктуры пользовательского интерфейса на стороне сервера может быть серьезным излишним. Гораздо удобнее использовать клиентскую часть серверно-агонистического фреймворка javascript, например. додзё, qooxdoo и т. д.

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

Вы можете иметь надлежащую инфраструктуру mvc во внешнем интерфейсе и только уровень модели на стороне сервера, который взаимодействует с приложением через успокоительный API (или RPC, если вы склонны).

Поскольку вы работаете с гибким фоном, я бы порекомендовал вам проверить платформу пользовательского интерфейса Ajax.org http://ui.ajax.org. Их структура пользовательского интерфейса основана на тэгах, как flex, и, хотя проект является новым, у них есть мощный набор виджетов и очень впечатляющие решения для построения графиков и привязки данных. Dojo и Ample SDK также используют систему компоновки виджетов на основе тегов.

Qooxdoo и extjs рекомендуют делать все, от макета и рендеринга до JavaScript, что может быть неудобно для вас.

Answer 3

Я являюсь архитектором одного мобильного веб-приложения, в котором 100 000 пользователей и 20 000 из них одновременно.

Для такого рода приложений (например, ограниченная пропускная способность) # 2 - единственный вариант, который я считаю.

Таким образом, серверная часть - это просто набор служб данных, а клиент использует чистый AJAX RPC. В нашем случае мы используем один статический файл index.htm, который содержит все. Кроме того, мы используем манифест HTML5 для сокращения количества обращений к серверу для сценариев / стилей / изображений при запуске. Плюс использование localStorage для сохранения состояния приложения и кэширования.

Начиная с MVC: существует множество шаблонизаторов , поэтому вы можете использовать все, что вам удобнее. Сами по себе шаблоны довольно компактны, так как не содержат никаких данных, так что (в нашем случае это нормально) включать их все.

Да, архитектура такого приложения должна быть продумана заранее. Вариант № 1 не так критичен - начальный уровень ниже.

Я не знаю, на какую платформу вы ориентируетесь, но, как я уже сказал, # 2, вероятно, является единственным вариантом для мобильных устройств.