Архітектура односторінкової веб-програми JavaScript?

Як слід структурувати складний односторінковий веб-додаток JS на стороні клієнта? Конкретно мені цікаво, як чітко структурувати додаток з точки зору його модельних об'єктів, компонентів інтерфейсу користувача, будь-яких контролерів та об'єктів, що обробляють сервер.

Спочатку MVC здавався придатним. Але з компонентами інтерфейсу, що вкладаються на різній глибині (кожен зі своїм способом дії на / моделювання даних та реагування на них, і кожен генеруючий події, який вони самі можуть або не можуть безпосередньо обробляти), схоже, MVC не може бути чітко застосований. (Але, будь ласка, виправте мене, якщо це не так.)

-

( Це питання призвело до двох пропозицій щодо використання ajax, який, очевидно, потрібен для будь-якого іншого, крім самого тривіального односторінкового додатка.)

MVC архітектура PureMVC / JS є найелегантнішим IMO. Я багато чому навчився з цього. Я також знайшов масштабну архітектуру програм JavaScript Ніколаса Закаса корисною для дослідження варіантів архітектури на стороні клієнта.

Ще два поради

1. Я знайшов управління, зосередження та керування введеннями - це сфери, які потребують особливої ​​уваги в веб-додатках на одній сторінці
2. Я також вважаю корисним відмовитись від бібліотеки JS, залишаючи відкритими двері, щоб змінити свою думку про те, що ви використовуєте, або змішати та відповідати, якщо виникне потреба.

Презентація Ніколаса Закаса, яку поділив Дін, - це дуже гарне місце для початку. Я також певний час намагався відповісти на те саме питання. Виробивши кілька широкомасштабних продуктів Javascript, подумав поділитися знаннями як еталонною архітектурою, якщо комусь це потрібно. Подивіться на:

http://boilerplatejs.org/

Він стосується поширених проблем розвитку JavaScript, таких як:

• Структурування розчинів
• Створення складної ієрархії модулів
• Самостійні компоненти інтерфейсу користувача
• Міжмодульний зв'язок на основі подій
• Маршрутизація, історія, закладки
• Тестування одиниць
• Локалізація
• Генерація документів

тощо.

Спосіб створення програм:

• Рамка ExtJS, додаток на одній сторінці, кожен компонент, визначений в окремому файлі JS, завантажується на вимогу
• Кожен компонент контактує з власною спеціалізованою веб-службою (іноді більше однієї), отримуючи дані в магазини ExtJS або спеціальні структури даних
• Візуалізація використовує стандартні компоненти ExtJS, тому я можу прив’язувати магазини до сіток, завантажувати форми із записів, ...

Просто виберіть рамку javascript і дотримуйтесь її найкращих практик. Мої фаворити - ExtJS та GWT, але YMMV.

НЕ розкачуйте для цього власне рішення. Зусилля, необхідні для дублювання того, що роблять сучасні рамки JavaScript, занадто великі. Завжди швидше адаптувати щось існуюче, ніж будувати все з нуля.

Question - What makes an application complex ? 

Відповідь - Використання слова "складний" у самому питанні. Отже, загальною є тенденція шукати складне рішення з самого початку.

Question - What does the word complex means ?

Відповідь - все, що невідомо або частково зрозуміло. Приклад: Теорія тяжкості навіть сьогодні для мене КОМПЛЕКСНА, але не для сера Ісаака Ньютона, який відкрив її в 1655 році.

Question - What tools can I use to deal with complexity ?

Відповідь - Розуміння та простота.

Question - But I understand my application . Its still complex ?

Відповідь - Подумайте двічі, бо розуміння та складність не існує. Якщо ви розумієте величезний величезний додаток, я впевнений, що погодитесь, що це не що інше, як інтеграція невеликих і простих одиниць.

Question - Why all of the above philosophical discussion for a question on 
           Single Page Application (SAP)?

Відповідь - Тому що,

-> SPA - це не якась нова технологія, яка була нещодавно винайдена, для чого нам потрібно винаходити колесо для багатьох речей, які ми робимо в розробці додатків.

-> Його концепція, обумовлена ​​потребою в кращій продуктивності, доступності, масштабованості та ремонтопридатності веб-додатків.

-> Це досить нещодавно визначена модель дизайну, тому розуміння SPA як схеми дизайну проходить довгий шлях у прийнятті обгрунтованих рішень про архітектуру SPA.

-> На кореневому рівні жоден SPA не є складним, оскільки, зрозумівши потреби програми та шаблону SPA, ви зрозумієте, що ви все ще створюєте додаток, майже так само, як ви робили раніше з деякими модифікаціями та перестановками у підході до розвитку.

Question - What about the use of Frameworks ?

Відповідь - Рамки є кодом / рішенням пластини котла для деяких загальновизначених та загальних моделей, отже, вони можуть знімати навантаження на х% (змінну, залежно від програми), але тоді не слід очікувати багато з них спеціально для важких і зростаючі програми. Це завжди хороший випадок, щоб повністю контролювати структуру вашої програми та потік, але найголовніше код для неї. У коді програми не повинно бути сірих або чорних зон.

Question - Can you suggest one of the many approaches to SPA architecture ?

Відповідь - Подумайте про власні рамки, виходячи з характеру вашої програми. Класифікуйте компоненти додатків. Шукайте існуючий фреймворк, близький до похідного фреймворку, якщо ви знайдете його, то використовуйте його, якщо ви не знайдете його, то я пропоную продовжити свій власний. Створення фреймворку - це досить зусилля, але дає кращі результати в довгостроковій перспективі. Деякі основні компоненти в моїй системі SPA будуть:

• Джерело даних: Моделі / Колекції моделей

• Позначення для представлення даних: Шаблони

• Взаємодія з додатком: Події

• Захоплення штатів та навігація: Маршрутизація

• Утиліти, віджети та плагіни: бібліотеки

Дайте мені знати, чи це допомогло в будь-який спосіб і удачі у вашій SPA архітектурі !!

Найкраще зробити, це подивитися приклади використання інших рамок:

TodoMVC демонструє безліч багатьох фреймворків SPA.

Ви можете використовувати java MVC Framework http://javascriptmvc.com/

Веб-додаток, над яким я зараз працюю, використовує JQuery, і я не рекомендував би його для будь-яких великих веб-додатків на одній сторінці. Більшість фреймворків, тобто Dojo, yahoo, google та інші, використовують простори імен у своїх бібліотеках, але JQuery цього не робить, і це є істотним недоліком.

Якщо ваш веб-сайт призначений для невеликого розміру, тоді JQuery буде добре, але якщо ви збираєтеся створити великий сайт, то я б рекомендував переглянути всі наявні рамки Javascript і визначити, який з них найбільше відповідає вашим потребам.

І я рекомендую застосувати шаблон MVC до вашого javascript / html, і, мабуть, більшість вашої об'єктної моделі для javascript може бути виконано як json, який ви фактично повертаєтесь із сервера через ajax, а javascirpt використовує json для візуалізації html.

Я рекомендую прочитати книгу "Аякс" в дії, оскільки вона охоплює більшість речей, які вам потрібно знати.

Я використовую Samm.js у кількох програмах на одній сторінці з великим успіхом

Я б пішов з jQuery MVC

Ознайомтесь з http://bennadel.com/projects/cormvc-jquery-framework.htm Бен досить гострий, і якщо ви копаєтесь у своєму блозі, у нього є приємні повідомлення про те, як CorMVC збирається і чому.

Альтернатива: подивіться на ItsNat

Подумайте в JavaScript, але кодуйте однаково на Java на сервері з тими ж API DOM, на сервері - це простіше керувати вашою програмою без спеціального клієнта / мостів, оскільки інтерфейс користувача та дані є разом.

Або подивіться на https://github.com/flosse/scaleApp

NikaFramework дозволяє створювати односторінкові програми. Також дозволяє записати HTML , CSS ( SASS ), JavaScript в окремі файли та з’єднати їх лише в один вихідний файл.

Я б рекомендував оглянути Єоман . Це дозволяє використовувати існуючу "кращу практику" для вашого нового проекту.

Наприклад:

якщо ви вирішили використовувати Angular.js, є генератор Yeoman , який дає вам структуру для маршрутизації, переглядів, служб тощо. Також дозволяють протестувати, мінімізувати код тощо.

Якщо ви вирішили використовувати Backbone, замовте цей генератор