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

StackOverflow https://stackoverflow.com/questions/32540

Вопрос

Как организован ваш JavaScript-код?Следует ли это шаблонам, таким как MVC, или чему-то еще?

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

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

Однако мне очень интересно, как другие люди создавали более существенные приложения на JavaScript.Меня не интересуют GWT или другие серверно-ориентированные подходы...просто в подходе "JavaScript + <generic web="" service-y="" thingy="" here="">"

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

Это было полезно?

Решение

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

Подумайте об этом:

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

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

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

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

Другие советы

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.Найти все({после:новая дата()}, функция myCallbackFunction);

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

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

В разделе "просмотры/ задачи/list.ejs"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просто небольшое уточнение.

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top