Как должно быть структурировано сложное одностраничное веб-приложение JS на стороне клиента? В частности, мне любопытно, как чисто структурировать приложение с точки зрения его объектов модели, компонентов пользовательского интерфейса, любых контроллеров и объектов, обрабатывающих персистентность сервера.
Сначала казалось, что MVC подходит. Но с компонентами пользовательского интерфейса, вложенными на разной глубине (каждый со своим собственным способом действия / реагирования на данные модели, и каждое генерирующее событие, которое они сами могут или не могут обрабатывать напрямую), не похоже, что MVC можно чисто применить. (Но, пожалуйста, поправьте меня, если это не так.)
-
( Этот вопрос привел к двум предложениям по использованию ajax, который, очевидно, необходим для чего-либо, кроме самого тривиального одностраничного приложения.)
Ответы:
MVC-архитектура PureMVC / JS - самая элегантная IMO. Я многому у него научился. Я также нашел Scalable JavaScript Application Architecture от Николаса Закаса полезной в исследовании вариантов архитектуры на стороне клиента.
Два других совета
источник
Презентация Николаса Закаса, которую поделил Дин, - очень хорошее место для начала. Я также какое-то время пытался ответить на тот же вопрос. После создания пары крупномасштабных продуктов Javascript, подумал о том, чтобы поделиться полученными знаниями в качестве эталонной архитектуры на случай, если это кому-то понадобится. Посмотри на:
http://boilerplatejs.org/
Он решает общие проблемы разработки Javascript, такие как:
и т.п.
источник
Как я создаю приложения:
Просто выберите фреймворк javascript и следуйте его лучшим практикам. Мои любимые - ExtJS и GWT, но YMMV.
НЕ используйте для этого собственное решение. Усилия, необходимые для дублирования того, что делают современные фреймворки javascript, слишком велики. Всегда быстрее адаптировать что-то существующее, чем строить все с нуля.
источник
Ответ - Использование слова «сложный» в самом вопросе. Следовательно, общей тенденцией будет поиск комплексного решения с самого начала.
Ответ - все, что неизвестно или частично понято. Пример: теория гравитации даже сегодня является СЛОЖНОЙ для меня, но не для сэра Исаака Ньютона, который открыл ее в 1655 году.
Ответ - Понимание и простота.
Ответ - подумайте дважды, потому что понимание и сложность не сосуществуют. Если вы разбираетесь в огромном огромном приложении, я уверен, что вы согласитесь, что это не что иное, как интеграция небольших и простых модулей.
Ответ - Потому что,
-> SPA - это не какая-то недавно изобретенная базовая технология, для которой нам нужно изобретать велосипед для многих вещей, которые мы делаем при разработке приложений.
-> Это концепция, обусловленная потребностью в улучшении производительности, доступности, масштабируемости и удобства обслуживания веб-приложений.
-> Это довольно недавно идентифицированный шаблон проектирования, поэтому понимание SPA как шаблона проектирования имеет большое значение для принятия обоснованных решений об архитектуре SPA.
-> На корневом уровне ни один SPA не является сложным, потому что после понимания потребностей приложения и шаблона SPA вы поймете, что все еще создаете приложение, почти так же, как и раньше, с некоторыми изменениями и перестановками в подходе к развитию.
Ответ - Фреймворки представляют собой шаблонный код / решение для некоторых часто идентифицируемых и общих шаблонов, поэтому они могут снимать нагрузку x% (переменная, основанная на приложении) от разработки приложения, но тогда от них не следует ожидать много, особенно для тяжелых и растущие приложения. Всегда хорошо иметь полный контроль над структурой и потоком приложения, но, что наиболее важно, над его кодом. В коде приложения не должно быть серых или черных областей.
Ответ. Подумайте о своей собственной структуре, основанной на характере вашего приложения. Классифицируйте компоненты приложения. Ищите существующий фреймворк, который близок к вашему производному фреймворку, если вы его найдете, используйте его, если вы его не нашли, я предлагаю продолжить со своим. Создание фреймворка требует определенных усилий, но в долгосрочной перспективе дает лучшие результаты. Некоторыми основными компонентами в моей структуре SPA будут:
Источник данных: модели / коллекции моделей
Разметка для представления данных: шаблоны
Взаимодействие с приложением: События
Захват состояния и навигация: маршрутизация
Утилиты, виджеты и плагины: библиотеки
Дайте мне знать, помогло ли это хоть как-то и удачи в архитектуре СПА !!
источник
Лучше всего посмотреть на примеры использования других фреймворков:
TodoMVC демонстрирует множество фреймворков SPA.
источник
Вы можете использовать javascript MVC framework http://javascriptmvc.com/
источник
Веб-приложение, над которым я сейчас работаю, использует JQuery, и я бы не рекомендовал его для каких-либо крупных одностраничных веб-приложений. Большинство фреймворков, например Dojo, yahoo, google и другие, используют пространства имен в своих библиотеках, а JQuery - нет, и это серьезный недостаток.
Если ваш веб-сайт должен быть небольшим, тогда JQuery подойдет, но если вы намереваетесь создать большой сайт, я бы порекомендовал просмотреть все доступные фреймворки Javascript и решить, какой из них больше всего соответствует вашим потребностям.
И я бы рекомендовал применить шаблон MVC к вашему javascript / html и, вероятно, большую часть вашей объектной модели для javascript можно было бы сделать как json, который вы фактически возвращаете с сервера через ajax, а javascirpt использует json для рендеринга html.
Я бы порекомендовал прочитать книгу Ajax в действии, так как она охватывает большую часть того, что вам нужно знать.
источник
Я с большим успехом использую Samm.js в нескольких одностраничных приложениях.
источник
Я бы пошел с jQuery MVC
источник
Посетите http://bennadel.com/projects/cormvc-jquery-framework.htm Бен довольно сообразителен, и если вы покопаетесь в его блоге, у него есть несколько хороших сообщений о том, как CorMVC собирается и почему.
источник
Альтернатива: взгляните на ItsNat
Думайте на JavaScript, но кодируйте то же самое на Java на сервере с теми же DOM API, на сервере намного проще управлять вашим приложением без настраиваемого клиента / мостов, потому что пользовательский интерфейс и данные вместе.
источник
Или посмотрите https://github.com/flosse/scaleApp
источник
NikaFramework позволяет создавать одностраничные приложения. Также позволяет записывать HTML , CSS ( SASS ), JavaScript в отдельные файлы и в конце объединять их только в один выходной файл.
источник
Я бы порекомендовал изучить Йомена . Это позволяет вам использовать существующие «лучшие практики» для вашего нового проекта.
Например:
если вы решите использовать Angular.js, есть генератор Yeoman , который дает вам структуру для маршрутизации, представлений, сервисов и т. д. Также позволяет вам тестировать, минимизировать ваш код и т. д.
Если вы решите использовать Backbone, проверьте этот генератор
источник