Какой архитектурный шаблон (ы) я должен использовать для своего RIA?

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

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

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

Исследования до сих пор:

  • RequireJS - Я посмотрел на RequireJS и подумал, что это отличная отправная точка, и все заработало.
  • JQuery - Не могу уйти от этой удивительной библиотеки.
  • Презентация Николаса Закаса о масштабируемой архитектуре приложения JavaScript - отличная идея, но как мне это реализовать? Я довольно плохо знаком с продвинутым JavaScript.

Мне также понадобится какой-то пул событий, чтобы управлять всеми этими событиями. Если я использую встроенный в JQuery пул событий "bind", "trigger", это не заставит меня отказаться от идеи Закаса о том, что только мое ядро ​​приложения должно иметь доступ к моей библиотеке JQuery?

Какой тип фреймворка мне следует рассмотреть, чтобы решить мою проблему?

Источник

1 ответ

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

В это время...

Вопрос об архитектурных шаблонах отличается от вопроса библиотек или структур.

АРХИТЕКТУРНЫЕ КОНСТРУКЦИИ ДИЗАЙНА полезны по многим причинам. Одной из причин будет достижение слабой связи в ваших модулях. Отличный пример того, как добиться слабой связи, можно найти в паттерне посредника.

Вопрос о том, какую систему использовать, имеет много точек принятия решений:

Тесты скорости:

Это то, что я считаю РАМОЧНЫМИ:

Я решил ограничить свой выбор рамок:

  1. Dojo: инструментарий, рабочий стол, Mobil, графика и векторизация
  2. YUI: инструменты разработчика, инфраструктура, утилиты, виджеты, галерея, проекты
  3. JQuery: ядро, пользовательский интерфейс, Mobil, плагины, графики, визуализация

Но... также необходима разбивка библиотек JavaScript:
MVC является наиболее часто используемым интерфейсным шаблоном. Однако мои заметки здесь еще не завершены. Даже у меня возникают проблемы с поиском статистики использования по пунктам, перечисленным выше.

Backbone.js (MVC)
Предназначен для потребления данных REST. Backbone имеет свою собственную систему событий и, таким образом, конкурирует с функциональностью jQuery.

Spine.js (MVC)

JavaScriptMVC (MVC)
MVC интегрированные инструменты разработки; используется с jQuery; Высоко модульный. Еще не уверен, можно ли это просто считать библиотекой или нет... но папочка, похоже!

AngularJS (MVC)
Разделение проблем, слабая связь и инверсия управления. Двусторонняя привязка данных

SproutCore (MVC)

YUILibrary (MVC)
Это действительно часть общей структуры YUI… но она была указана в исходной статье.

Broke.js (MVC)
Документация в настоящее время оставляет желать лучшего.

Fidel.js (MVC)

Sammy.js (MVC)
Предназначен для потребления данных REST.

KnockoutJS (MVVM)

ВОПРОСЫ:

  • Почему так мало прямых реализаций MVVM?
  • Двухстороннее связывание - это то же самое, что и MVVM?
  • Если да, то почему некоторые из этих библиотек (которые выполняют двустороннее связывание) считают себя MVC?

МОДУЛЬНЫЙ JAVASCRIPT: AMD, CommonJS и реализации на основе обещаний:
Я все еще обрисовываю в общих чертах эту область. Тем не менее, ниже приведены некоторые области, которые я использую для вдохновения.

ВОПРОСЫ:

  • Существуют ли разные "ароматы" AMD (в разных статьях говорится, что да)?
  • Что означает "основанный на обещаниях"?

СОЗДАНИЕ ВИДЖЕТОВ И ПЛАГИНОВ:
Как только вы решите, какой тип AMD должны использовать ваши модули, вы действительно можете начать что-то писать.

ВОПРОСЫ:

  • В чем разница между плагином и виджетом?

ГЛАВНЫЕ ПРИМЕЧАНИЯ:
Я бы посоветовал посмотреть, как каждая из ваших платформ реализует различные модули. Посмотрите на код, необходимый для достижения чего-либо. Чувствуется ли это правильно? Это чувствует себя неуклюжим?

МОИ НАЧАЛЬНЫЕ ЧУВСТВА:
Смотря на тенденции, использование, скорость и обширность вариантов поддержки сообщества...jQuery далеко впереди.

ЦЕЛЬ:
Конечная цель - выбрать фреймворк, любые / все библиотеки и определить общий подход для загрузки и создания слабосвязанных модулей JavaScript.

Количественная оценка стоимости по риску:
Прямая оценка стоимости трудна, но вы можете объяснить риск. В своем окончательном решении вы также должны принять во внимание тенденции, перечисленные выше. Но, в целом, я бы разбил расходы на 3 области, определяющие РИСК:

  • Знакомство: с чем ваша команда сейчас наиболее знакома?
  • Ускорение: Сколько дополнительных усилий потребуется для "наращивания" каждой инфраструктуры и библиотеки?
  • Лицензирование: есть ли здесь какие-то препятствия?

Риск. После оценки вы можете по праву объяснить, ПОЧЕМУ вы можете присвоить один вариант как низкий, средний или высокий.

@ErezCohen

Мы являемся магазином ASP.NET, поэтому мы используем Web API для нашего RESTFUL-сервера. А так как будущее за разработкой компонентов в стиле JavaScript, мы решили использовать jQuery & RequireJS в качестве стандартного базового уровня на всех наших страницах. Кроме того, мы интенсивно используем Deferreds в наших контроллерах.

Что касается MVC на стороне клиента, слишком многие из упомянутых "фреймворков" являются более причудливыми, чем что-либо еще (и многие утратили популярность). Кроме того, было больше смысла рассматривать возможности MVC/MVVM как одноразовое дополнение, когда требования диктуются, а не стандартом. И, честно говоря, так как мы находим, что делать вызовы Ajax легко, в огромных инфраструктурах выполнение простой привязки данных казалось глупым (единственное реальное преимущество - двусторонняя привязка для некоторых сложных случаев). Кроме того, подумайте о том, какая боль будет отсоединять некоторые из этих фреймворков, когда они перестают быть популярными.

Конечно, у нас есть талант сделать это самостоятельно... вы не можете. Если ваша команда не очень хорошо работает с JavaScript, попробуйте Angular, потому что он был разработан для "дизайнеров", а не программистов. В качестве альтернативы, если ваша команда может самостоятельно развернуть систему и хочет создать каркас для контроллеров, тогда jQuery Widget Factory будет полезен. Тем не менее, простое использование Module Pattern для ваших контроллеров тоже хорошо (это то, что мы делаем). И... это прекрасно работает... и очень чисто.

Источник
Другие вопросы по тегам