Архитектура для почти готовых веб-приложений на основе JavaScript?

Question

Я знаю, что MVC высоко оценен для приложений PHP, но я совсем не уверен, что он вписывается в JavaScript.Если вы думаете иначе, тогда, пожалуйста, объясните, как и где вы обрабатываете общие сценарии, такие как запросы AJAX, сохранение данных (автономное хранение), представление, как вы обрабатываете логику контроллера (у вас есть фронт-контроллер?) И т. Д.*

А как насчет Model-View-Presentation?

Я использую ExtJS и использую сервер только для постоянного хранения данных.

Answer 1

Я использую ту же архитектуру: преимущественно ExtJS поверх PHP-фонов.

Мое решение:

• Строгая связь JSON-RPC с сервером. API на стороне сервера достаточно чист, чтобы он также являлся нашим сторонним интерфейсом API. Принудительное использование API-интерфейса, аналогичного используемому сторонними интерфейсами, заставляет серверный код оставаться чистым и минимальным, что хорошо для безопасности и производительности.
• Сильно компонентная архитектура, разделенная на модули, которые группируют компоненты (обычно производные Ext.Panel). Каждый компонент знает, как запрашивать свою начальную конфигурацию и данные через вызовы JSON-RPC, обрабатывать себя и сохранять свое состояние, если это необходимо. Я стараюсь поддерживать связь между компонентами чистой и задокументированной.
• Архитектура по требованию, загрузка дополнительных компонентов через файлы JavaScript при необходимости. Весь код предназначен для инициализации через обратные вызовы, так что компоненты могут загружать свои зависимости с сервера и отображать только пустой заполнитель перед своей инициализацией.

Отдельные компоненты могут использовать шаблон MVC, где это имеет смысл. Ext в любом случае поощряет MVC, разделяя данные на хранилища и имея отдельную инфраструктуру рендеринга (хотя она и смешивает логику контроллера с визуализированными компонентами).

Answer 2

Если вы планируете кодировать свой пользовательский интерфейс исключительно с помощью JavaScript, вы можете подумать, что ваш конец PHP - это скорее веб-служба или API .

По сути, ваш View - это то, что вы пишете в Ext JS на JS. Для работы с вашими данными внешний интерфейс Ext будет выполнять запросы к вашему «сервису». По сути, на вашем сервере будет использоваться своего рода архитектура контроллера модели, в которой работа контроллера будет заключаться в обработке запросов и выводе JSON (для использования внешним интерфейсом Ext)

По сути, "представление" в вашем бэкэнде будет просто выводиться из json_encode, который затем используется вашим фактическим представлением на основе Ext.

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

Это в основном зависит от того, насколько сильно вы хотите отделить логику.

Answer 3

При написании почти полных приложений на JavaScript вы можете думать о MVC как:

• Вид: ДОМ
• Контроллер: Ваш JavaScript
• Модель: комбинация JavaScript Ajax Calls и их PHP (или любых других) внутренних компонентов

PureMVC - это чрезвычайно крутая среда MVC. Вы должны проверить это.

Answer 4

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

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

Вы пытаетесь свести его к технологическому уровню, и это на самом деле не имеет никакого смысла.Вы можете сделать правильный MVC с хорошей основой.Просто чтобы прояснить ситуацию, простой ванильный PHP не дает хорошей поддержки MVC.Хороший фреймворк, такой как CakePHP или CodeIgniter, будет.

JS - это просто хороший способ обогатить опыт работы на стороне клиента.Это означает, что, если вы не выполняете JS на стороне сервера, единственное место, где у вас будет JS, - это само представление.По сути, запросы AJAX не имеют ничего общего с MVC.Так же как и постоянство данных.Если вы не реализуете свой собственный контроллер (и у вас лучше есть чертовски веская причина сделать это самостоятельно), вам не стоит беспокоиться о его внутренней логике.используйте правильные рамки, и все встанет на свои места.