Ajax Architecture - MVC? Другой?

Question

Привет всем, я смотрю на создание ajax-сайта, и я пытаюсь потратить некоторое время на обдумывание архитектуры.

Я использую Code Igniter и jquery. Мой первоначальный мыслительный процесс состоял в том, чтобы выяснить, как копировать MVC на стороне javascript, но кажется, что M и C на самом деле не имеют большого места.

Большая часть JS - это вызовы ajax, НО я вижу, как он выходит за рамки этого, с большим количеством манипуляций с DOM, а также с изучением клиентской базы данных HTML5. Как я должен думать об архитектуре этих файлов? Имеет ли смысл преследовать MVC? Должен ли я пойти по пути JQuery плагин? Я заблудился относительно того, как действовать, и я хотел бы несколько советов. Спасибо всем!

Answer 1

Я создал программу на JavaScript в стиле MVC. В комплекте с M и C. Возможно, я сделал неправильный шаг, но в итоге я создал собственную библиотеку диспетчера событий. Я убедился, что различные уровни обмениваются данными только с использованием протокола сообщений, который может быть преобразован в чистые объекты JSON (даже если я на самом деле не делаю этот шаг преобразования).

Так что jquery живет в основном в V части архитектуры MVC. На стороне M и C у меня есть прежде всего код, который может работать в автономной CLI-версии spidermonkey или в серверной реализации javascript для носорогов, если это необходимо. Таким образом, если требования изменятся позже, я смогу запускать слои M и C на стороне сервера, передавая через эти сообщения json сторону V в браузере. Чтобы изменить это, потребовались бы только некоторые изменения в моем диспетчере сообщений. В будущем, если браузеры получат какие-то одноранговые технологии, я мог бы, например, запускать их в разных браузерах.

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

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

Другая большая реализация функциональной реактивной функции - это кварцевый композитор, который поставляется бесплатно с инструментами разработчика Apple (которые бесплатны при покупке любого Mac). Если это доступно для вас, внимательно посмотрите на это, и как это работает. (у него даже есть патч javascript, так что вы можете создать прототип вашего приложения с помощью встроенного слоя представления)

Основной вывод из функционально-реактивной парадигмы состоит в том, чтобы убедиться, что представление не поддерживает никаких состояний, кроме того, которое вы только что дали для отображения. Чтобы выразить это более конкретно, я начал с сообщений типа «Добавить объект на экран», «удалил объект с экрана», и теперь я больше склоняюсь к «отображению этого списка объектов, и я Позвольте вам выяснить наиболее эффективный способ перехода от текущего отображения к тому, что я сейчас хочу, чтобы вы отображали ». Это устранило целый ряд ошибок, связанных с небрежно управляемым состоянием.

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

В любом случае, это моя маленькая напыщенная речь. Дайте мне знать, если у вас есть дополнительные вопросы о моем военном опыте.

Answer 2

На риск быть воспламененным, я бы предложил другой фреймворк помимо JQuery, иначе вы рискуете достичь потолка производительности. Его плагины в режиме ala-mode также представляют собой небольшую проблему при попытке разделить вас M, V и C.

Dojo хорошо известен своими хранилищами данных для привязки к данным на стороне сервера с различными транспортными протоколами, а также своей объектно-ориентированной, быстро освещаемой системой виджетов, которую легко расширять и настраивать. У него есть стиль, который помогает вести вас в чистый, хорошо разделенный код - хотя это не строго MVC. Это потребует немного дополнительного планирования.

У Dojo более крутая кривая обучения, чем у JQuery.

Еще к вашему вопросу. AJAX-вызовы и объект (или хранилище данных), который хранит и запрашивает эти данные, будут вашей моделью. Виджеты и CSS будут вашим видом. А контроллером в основном будет код вашего приложения, связывающий все это вместе.

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

Answer 3

JavaScriptMVC (javascriptmvc.com) - отличный выбор для организации и разработки крупномасштабного приложения JS.

Архитектурный дизайн очень практичен. Есть 4 вещи, которые вы когда-либо будете делать с JavaScript:

1. Ответить на событие
2. Запрос данных / управление сервисами (Ajax)
3. Добавить информацию о домене к ответу ajax.
4. Обновление DOM

JMVC разбивает их на шаблон Модель, представление, контроллер.

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

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Далее идет модель. JMVC предоставляет мощный класс и базовую модель, которая позволяет быстро организовать функции Ajax (# 2) и обернуть данные функциональностью, специфичной для домена (# 3). После завершения вы можете использовать модели из вашего контроллера, как:

Todo.findAll ({after: new Date ()}, myCallbackFunction);

Наконец, когда вернутся ваши задачи, вы должны отобразить их (# 4). Здесь вы используете вид JMVC.

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

В 'views / todos / list.ejs'

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC предоставляет гораздо больше, чем архитектура. Это поможет вам в любой части цикла разработки с:

• Генераторы кода
• Интегрированное тестирование браузеров, Selenium и Rhino
• Документация
• Сжатие скрипта
• Сообщение об ошибке

Answer 4

Я думаю, что в JavaScript определенно есть место для "M" и "C".

Выезд AngularJS .

Это поможет вам с вашей структурой приложения и строгим разделением между «представлением» и «логикой». Предназначен для совместной работы с другими библиотеками, особенно с jQuery.

Полная среда тестирования (unit, e2e) + внедрение зависимостей, поэтому тестирование с помощью AngularJS является простым делом.

Answer 5

Существует несколько JavaScript MVC-фреймворков, у этого есть очевидное имя: http://javascriptmvc.com/