Альтернативные «архитектурные» подходы к клиентскому коду javaScript? - PullRequest
16 голосов
/ 28 августа 2008

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

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

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

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

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

Ответы [ 7 ]

6 голосов
/ 28 августа 2008

.. но у Javascript есть много аспектов, которые равны OO.

Учтите это:

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

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

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

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

3 голосов
/ 23 августа 2009

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
  • Документация
  • Сжатие скрипта
  • Сообщение об ошибке
2 голосов
/ 29 августа 2008

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

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

1 голос
/ 10 октября 2008

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

Совершенно возможно написать 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.

1 голос
/ 15 сентября 2008

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

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

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

1 голос
/ 15 сентября 2008

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

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

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

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

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

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

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

0 голосов
/ 28 августа 2008

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

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

...