PHP MVC с чистым Javascript View: хорошая практика?

Question

Мой вопрос может быть недостаточно понятным, поэтому позвольте мне объяснить ситуацию:

Я работаю над большим AJAX-сервером, построенным на стороне сервера, с PHP, использующим CodeIgniter. Эта структура четко работает с моделями, контроллерами и представлениями. Файлы представлений отображаются в HTML, а затем отправляются клиенту, который выполняет с ним некоторые js-процедуры (например, присоединение событий).

Этот способ работы кажется мне странным, поскольку он разделяет представление между серверной стороной и клиентской стороной.

Я думал о переносе всех обработок View на клиентскую часть, которая будет динамически создавать html в js. Серверная часть будет отправлять только необработанные данные.

Я работал таким образом над небольшими проектами и был очень доволен результатом (легко понятным, переносимым и многократно используемым).

Это правильный способ реализации приложения MVC? Какие-нибудь советы относительно этого отражения?

Answer 1

Я сделал в значительной степени то, что вы описываете в довольно большом приложении для обработки данных в качестве внутреннего приложения.В моем случае я использовал ExtJS для рендеринга / просмотра на стороне клиента и общался с конечной точкой C # WCF, доступной на веб-сервере.По существу запросы были сделаны / отправлены, а ответы были сериализованы в / из JSON.Он прошел очень гладко, как только некоторые изломы были решены.Первоначальный автор написал собственный сериализатор для непосредственного выполнения непосредственных результатов со своего уровня данных ... это приводит к тому, что по каналу идет много дополнительных данных.Пока вы осмотрительны с данными полезной нагрузки, они могут быть очень эффективными.

Некоторые предостережения, хотя ...

• Вероятно, вам следует избегать этого, если вы ожидаете, что пользователи без включенного JavaScriptиметь возможность доступа к сайту (все, что связано с денежными транзакциями от внешних пользователей).
• Вы захотите документировать свою методологию как можно более четко.
• Поиск разработчиков для задач обслуживания после того, как вы внедрилиПриложение будет очень сложным.(многие серверные разработчики стесняются, боятся или просто неэффективны с навыками JS.

По большей части это бросок, я считаю, что большинство людей, по крайней мере, включили JS,но могут быть заблокированы другие вещи. На данный момент поддержка AJAX / XmlHttpRequest практически универсальна.

Что касается шаблонов для отображения на стороне клиента, то здесь есть несколько вариантов (но это отдельное обсуждение).

Answer 2

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

(В результате мой код изменился с 90% PHP с 10% JavaScript ... до 65% JavaScript с 35% PHP.)

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

Хотя я не использую шаблоны HTML. Я не думаю, что естественно иметь 100% разделение между HTML и программированием. Я думаю, что простые циклы программирования, условные операторы и триггеры JavaScript прекрасно сочетаются с HTML.

Answer 3

Создание представлений JavaScript прекрасно работает в шаблоне MVC, поскольку ваше представление не смешивается с вашей бизнес-логикой или моделью.

Однако у использования полных представлений JavaScript есть несколько недостатков.В основном это исключает возможность постепенного ухудшения качества, если у клиента отключен JavaScript.Кроме того, некоторые браузеры (IE) не имеют очень быстрого движка JavaScript, который замедляет загрузку вашей страницы.Это правда, что некоторые представления разделены между клиентом и сервером, но это имеет смысл, когда вы об этом думаете.

В большинстве случаев HTML-код, который вы отправляете клиентам, одинаков для всех(если вы не обнаруживаете браузер на стороне сервера).Однако подпрограммы JavaScript отличаются.Если вы используете библиотеку, такую ​​как JQuery, она будет скрыта от вас, но код, который выполняется на каждом клиенте, может сильно отличаться.Одним из примеров этого может быть XMLHttpRequest, который используется браузером firefox / webkit и т. Д., И активный элемент управления x, который используется IE.Поскольку html-часть контента одинакова для всех, имеет смысл создать ее на сервере, а поскольку JavaScript-представление может отличаться, имеет смысл, что оно построено на стороне клиента.

НТН

Answer 4

Звучит так, будто вы в одном шаге от перехода от паттерна MVC к паттерну MVVM .

MVVM идеально подходит для сложных пользовательских интерфейсов (это именно то, что вы будете создавать со всеми AJAX, JavaScript и так далее), потому что в этом случае ваше представление HTML сможет выступать в качестве контроллера через JavaScript. Для этого есть библиотека (предупреждение: я никогда не использовал ее, но она выглядит многообещающе) под названием Knockout JS .

Answer 5

Есть ли что-нибудь более динамичное на самом сайте?Делает ли он больше вещей AJAXy, динамически обновляет части сайта и т. Д.?Если это так, может быть разумно иметь сайт только для Javascript.

Поскольку это не так, как традиционно работает сеть, отправка HTML с сервера по-прежнему является базовой линией.Если ваши страницы в основном статичны, если вы хотите обслуживать более старых клиентов, аудиторию, которая может отключить Javascript, аудиторию, которая может иметь проблемы с доступностью страниц Javascript, альтернативные клиенты, которые не могут понять Javascript или поисковые системы, вам следует обслуживать HTMLстраницы с сервера.В этом нет ничего плохого, это просто, просто и надежно.Есть много вещей, которые следует учитывать при повторном изобретении колеса в Javascript на стороне клиента.Если вы не сможете эффективно использовать этот потенциал (см., Например, высокодинамичные страницы Facebook или Twitter), то может доставить вам больше хлопот, чем это стоит вашим пользователям.

Answer 6

Если вы будете думать так, как есть основное представление, которое создает движок html / js и пару представлений ajax с потоками данных - это будет вполне нормально с точки зрения MVC imo.