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

Ответ 1

.. но Javascript имеет много аспектов, которые являются OO.

Рассмотрим это:

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

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

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

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

Ответ 2

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

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

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

JMVC разбивает их на шаблон Model, View, Controller.

Во-первых, и, вероятно, самым важным преимуществом является контроллер. Контроллеры используют делегирование делегирования, поэтому вместо добавления событий вы просто создаете правила для своей страницы. Они также используют имя контроллера для ограничения объема работы контроллера. Это делает ваш код детерминированным, то есть, если вы видите, что событие происходит в элементе '#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);

Наконец, как только ваши todos вернутся, вы должны их отобразить (# 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 обеспечивает намного больше, чем архитектура. Это помогает вам в любой части цикла разработки:

• Генераторы кода
• Тестирование интегрированного браузера, селена и носорога
• Документация
• Script сжатие
• Отчет об ошибках

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

Простое уточнение.

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

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

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

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

Ответ 7

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

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