Альтернативные "архитектурные" подходы к клиентскому коду javaScript?

Question

Как организован ваш код javaScript? Это следует за образцами как MVC, или что-то еще?

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

• Модель - это дерево JSON, которое расширяется с помощью помощников.
• Представление - это классы DOM plus, которые его настраивают
• Контроллер - это объект, к которому я подключаю обработку событий и запускаю представление или манипулирование моделью

Однако мне очень интересно узнать, как другие люди создали более существенные приложения javaScript. Я не заинтересован в GWT или других серверно-ориентированных подходах... просто в подходе "javaScript + <универсальный веб-сервис, и так далее>"

Примечание: ранее я говорил, что javaScript "не совсем ОО, не совсем функциональный". Это, я думаю, отвлекло всех. Скажем так, потому что javaScript во многих отношениях уникален, и я исходил из строго типизированного фона, я не хочу приводить известные мне парадигмы, но они были разработаны на самых разных языках.

Answer 1

... но у Javascript есть много аспектов, которые являются ОО.

Учти это:

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

Я использовал эту технику для создания классов javascript на уровне страницы, которые имеют свое собственное состояние, это помогает сохранить его в себе (и я часто определяю области, которые я могу использовать повторно и помещать в другие классы).

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

Answer 2

JavaScriptMVC - отличный выбор для организации и разработки крупномасштабного 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 3

MochiKit великолепен - и был моей первой любовью, так сказать, в отношении библиотек js. Но я обнаружил, что, хотя MochiKit имеет очень выразительный синтаксис, мне он показался не таким удобным, как Prototype/Scriptaculous или jQuery для меня.

Я думаю, что если вы знаете или любите python, то MochiKit - хороший инструмент для вас.

Answer 4

Просто быстрое разъяснение.

Вполне возможно написать GWT-приложения, которые не ориентированы на сервер. Я предполагаю, что под Server-Oriented вы имеете в виду GWT RPC, который нуждается в Java-интерфейсе.

Я написал приложения GWT, которые очень "MVC-иш" только на стороне клиента.

• Модель была графом объектов. Хотя вы кодируете на Java, во время выполнения объекты находятся в javascript без необходимости какой-либо JVM на стороне клиента или сервера. GWT также поддерживает JSON с полной поддержкой анализа и манипуляции. Вы можете легко подключиться к веб-сервисам JSON, см. Пример 2 для гибридного приложения JSON.
• Представление было составлено из стандартных виджетов GWT (плюс некоторые из наших собственных составных виджетов)
• Слой контроллера был аккуратно отделен от View через шаблон Observer.

Если ваш "строго типизированный" фон написан на Java или похожем языке, я думаю, вам следует серьезно рассмотреть GWT для больших проектов. Для небольших проектов я обычно предпочитаю jQuery. Предстоящий GWTQuery, работающий с GWT 1.5, может изменить это, хотя и не в ближайшем будущем из-за обилия плагинов для jQuery.

Answer 5

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

До сих пор я вижу очень большую разницу в подходе, использующем что-то вроде Ext и другие, такие как JQuery UI, Scriptaculous, MochiKit и т. Д.

С Ext, HTML - это всего лишь один заполнитель - пользовательский интерфейс идет сюда. С тех пор все описывается в JavaScript. Взаимодействие с DOM сводится к минимуму под другим (возможно, более сильным) уровнем API.

С другими наборами я начинаю с небольшого проектирования HTML-кода, а затем расширяю DOM напрямую эффектными эффектами или просто заменяю ввод формы здесь, добавив туда.

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

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

Новый игрок, которого я полностью оценил, - это Sproutcore. Это похоже на Ext в подходе, где DOM скрыт, и вы в основном хотите иметь дело с API проекта.

Answer 6

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

Некоторое время назад я видел одну попытку, когда кто-то создал среду для моделирования данных в JavaScript, очень похожую на то, как SQLite принадлежит приложению. Это было похоже на Model.select( "Продукт") и Model.update( "Продукт", "Некоторые данные..."). Это была в основном нотация объекта, которая содержала набор данных для управления состоянием текущей страницы. Однако, в ту минуту, когда вы обновите, все эти данные будут потеряны. Я, вероятно, выключил синтаксис, но вы поняли.

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

Answer 7

Не уверен на 100%, что вы здесь имеете в виду, но я скажу, что после работы с ASP.NET в течение последних 6 лет мои веб-страницы теперь в основном управляются JavaScript, когда сервер выполняет базовый рендеринг страниц. Я использую JSON для всего (уже около 3 лет) и использую MochiKit для своих нужд на стороне клиента.

Кстати, JavaScript - это ОО, но, поскольку он использует прототипное наследование, люди не считают его таким. Я также утверждаю, что он также функционален, все зависит от того, как вы его пишете. Если вы действительно заинтересованы в стилях функционального программирования, посмотрите MochiKit - он вам может понравиться; он немного склоняется в сторону функционального программирования JavaScript.