Как объединить JMVC (javascript-mvc) и MVC на стороне сервера вместе


Я задавал этот вопрос несколько дней назад здесь, и никто на него не ответил.
Я тоже задавал этот вопрос в forum.javascriptMVC.com, и теперь у меня есть ответ, однако мне нужно немного больше идей.

Вопрос:

I read javascriptMVC's documents and I loved it. 
But I don't know how to use it in a large scale project.

Я думаю, что на стороне сервера платформа MVC необходима или может очень помочь. И я работал с PHP-фреймворками на стороне сервера.

Я в замешательстве, мое понимание проектов JavaScriptMVC заключается в том, что они обрабатывают события на стороне клиента в браузере, захватывают события, выполняют AJAX запросы, управляйте ответами/данными с сервера, а также показывайте их пользователю в графическом интерфейсе.

Я знаю, что в проектах PHP MVC у нас также есть контроллеры (и действия), что любой из них представляет собой отдельную страницу с одной точкой входа, я хочу сказать, что эти страницы представляют собой целые HTTP-запросы.

Я думаю, что комбинация этих двух фреймворков будет в виде одного или нескольких тяжелых файлов (включая js, css, imgs и т. Д.), Которые загружаются и управляются другая библиотека Javascript, такая как steal.js . Теперь пользователь может работать с сайтом и его действиями (как событиями), которые приводят к запуску функций js, которые могут что-то изменить в пользовательском интерфейсе или вызвать запрос AJAX, как в почте Yahoo, где большинство событий происходит на одной странице.

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

Наконец

  • Я хочу знать о различных аспектах использования этого метода (JMVC+MVC). (Я использую Yii в качестве серверной платформы MVC и JavaScriptMVC в качестве клиентской платформы MVC).
  • Я также хочу знать об управлении данными на стороне клиента.
  • Я хотел бы понимаете, как можно использовать AJAX и веб-сокеты, где мы можем использовать AJAX и где мы можем использовать websockets?.
  • Я хочу понять о локальном хранилище, как мы можем использовать его для имитации управления данными страниц и, возможно, кэширования, как мы можем кэшировать данные, поступающие с сервера в виде JSON в виде страницы? Я работаю над очень большим проектом и хочу заложить очень прочный фундамент.
Author: Manquer, 2013-04-02

3 answers

Скажите, что у вас есть фреймворк JMVC, где

  • Модель получает данные с сервера с помощью AJAX-запроса, ожидая результатов JSON.
  • Представление не зависит от сервера, более того, оно предоставляет необработанный HTML.
  • Контроллеры не полагаются на сервер для большего, чем обслуживание файлов JS.

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

Теперь давайте посмотрим, как определить серверную платформу. Как я вижу, у нас есть несколько вариантов, все они довольно похожи, хотя и несколько отличаются (все возвращают некоторые данные в формате JSON):

  • Полноценный MVC, такой как CakePHP
  • Пользовательская реализация
  • Реализация веб-сервиса

Лично я бы использовал веб-сервис, и у меня уже есть. Или, скорее, я использовал веб-сервис JSON-RPC на основе WebSocket. Использование полноценного MVC будет иметь недостатки в ремонтопригодности и, что немаловажно, в нагрузке на сервер. Но это очень возможно, просто реализуйте представление, которое форматирует страницу как JSON...

Создание клиента JMVC, на мой взгляд, не означает, что он не может запрашивать новый HTML с сервера. Но это означает, что запрошенный HTML-код должен быть свободен от данных, кроме метаданных, которые Java-представление должно знать, куда помещать данные, полученные, например, из веб-сервиса.

Таким образом, главная страница в JMVC может просто содержать одиночный

<div id=content></div>

И щелчки меню могут извлекать подстраницу с сервера и загружать содержимое в content. Затем загруженный контент может содержать еще немного javascript, который запускает запросы веб-служб для получения данных с сервера, для отображения в пустых заполнителях, которые он, в свою очередь, содержит.

 3
Author: fredrik, 2013-04-08 06:18:11

Первая проверка https://stackoverflow.com/a/4458566/718224 после этого вы можете двигаться вперед.


Попробуйте это (из https://stackoverflow.com/a/8424768/718224)

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

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

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

Если у вас есть статическая html-страница, которая строится с использованием AJAX-запросов, то вам может вообще не потребоваться использовать представления на стороне сервера. Ваши контроллеры будут больше чем, скорее всего, будет выводить данные JSON. Если это так, то это не делает модели и контроллеры менее полезными.


Попробуйте это (из https://stackoverflow.com/a/8424760/718224)

Если вы используете какой-либо из основных фреймворков PHP (CakePHP, Code Igniter, Symfony и т.д.), То вы уже используете MVC. Если ваша логика на стороне сервера сложнее, чем просто несколько действительно простых сценариев, чем вы, вероятно, должны использовать одну из перечисленных платформ, используя MVC на сервере и клиенте.

Многие (большинство?) более крупные веб-приложения, создаваемые сегодня, переходят к использованию платформы MVC как для кода приложений на стороне клиента, так и на стороне сервера. Это фантастический шаблон для разделения проблем для многих крупных приложений, особенно приложений сервера запросов/ответов и приложений браузера, управляемых событиями.


Попробуйте это (из https://stackoverflow.com/a/8427063/718224)

Backbone.js подключает ваше приложение через спокойный JSON интерфейс. Я честно нахожу, что это прекрасно работает в сочетании с платформой MVC. Если вы создадите API RESTful, вы сможете довольно легко позволить своему серверу управлять обновлениями CRUD. Весь ваш код на стороне сервера будет отвечать за сохранение и отправку объектов JSON обратно в Backbone.js . Тогда пусть большая часть вашей логики и магии произойдет в Backbone.js рамки.


Попробуйте это (из https://stackoverflow.com/a/8078282/718224)

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

Далее, эти клиентские фреймворки разработаны специально для работы с вашими внутренними фреймворками MVC. Backbone.js (поскольку вы специально отметили его) модели и коллекции работают с сервисами REST. Они будут разговаривать с помощью глаголов GET/POST/PUT/DELETE и в конечном итоге будут общаться с вашими контроллерами на серверной части, когда они делают асинхронные запросы.

В случае магистрали он использует JSON вместо HTML. В случае Rails это действительно легко обрабатывается в контроллере. Если запрос является HTML-запросом, то вы возвращаете представление в формате HTML. Если это запрос JSON (*.json или тип содержимого), то контроллер возвращает представление данных в формате JSON. Я предполагаю, что в Django так же просто, как и в Rails, чтобы один и тот же контроллер реагировал на несколько запросов контента (HTML, XML, JSON и т.д.)

Пусть это поможет вам.

 3
Author: Tony Stark, 2017-05-23 12:24:27

Веб-приложения на стороне клиента и расширенные веб-страницы на стороне клиента часто используют jmvc backbones и т. Д. и с такими библиотеками js и технологиями HTML5, такими как webstorage, У вас может быть больше приложений, таких как веб-сайты, на которых все происходит на стороне клиента, например, управление шаблонами и т. Д. и просто у нас есть запрос/ответ ajax на серверы для получения/установки данных или обновления статуса. и в первом разделе они правы, сайт jmvc больше похож на сайты с одной страницей. ie hotmail yahoo и т.д.

 2
Author: john amine, 2013-09-13 12:18:50