Хотел сделать MVC, но вот что получилось...

Хотел сделать велосипед, а получилось кресло-качалка... Нельзя сказать, что это далеко не MVC, потому что к MVC это не имеет вообще никакого отношения. Зачем Вы вообще MVC упоминаете?

Если же говорить о Вашем подходе с точки зрения упора на жабаскрипт, то имейте в виду по крайней мере 2 момента:

- не все поисковики правильно реагируют на такие сайты и правильно отображают их в поиске;

- не у всех пользователей одинаково работают скрипты и правильно отображаются такие сайты.

Ну не обязательно цепляться именно за MVC - это больше к объектно-ориентированному программированию относится, чем к вашему случаю. То есть когда имеется набор классов, которые взаимодействуют между собой как MVC или MVP или еще как-то. У вас же получилась просто архитектура - часть кода на клиенте, часть на сервере, а все вместе это проект. Если разделить клиентский html файл на собственно сам код интерфейса, и отдельный файл с JS кодом, будет ближе к вашей изначальной задумке, но, как уже писали выше, это не будет иметь отношения к паттернам.

Поздравляю, вы открыли SPA. Минусы - скорость разработки. Плюсы - скорость работы. Паттерн, скорее всего, MVVM. Только в стадии зародыша.

Понятно. А что получится, если частично перенести обработку данных от клиента (JS) на сервер (PHP)?

Я поясню: страницы будут все-таки формироваться с помощь PHP на стороне сервера, но связь с БД будет по-прежнему происходить через тот "коннектор", который я описал в стартовом топике (одиночный скрипт, который принимает (POST запрос), обрабатывает и отдает (JSON) данные). На клиенте, конечно, придется оставить некоторый интерактив на JS (например, подсветка неверно заполненных полей, предварительная валидация данных и т.д.).

Кстати, PHP скрипты, расположенные на одном сервере быстро друг с другом взаимодействуют?

Вообще у меня задумка была такая, что бы ВСЕ данные проходили (и В базу и ИЗ базы) через одно место, где бы исключалась любая возможная не корректность. И я бы хотел это в любом случае сохранить.

Рамарио, и там и там данные нужно проверять. На клиенте - для валидной работы представления, на сервере - для безопасности. Где страницы будут формироваться не играет роли, есть разные подходы с шаблонизацией: отдавать JSON и на JS заполнять шаблон (нагрузка на CPU клиента), или подготавливать шаблон и отдавать распарсенный HTML, тогда нагрузка ложится на сервер. Первый случай вредный для смарфтонов, а второй - для сайтов с запредельной посещаемостью. И да, шаблоны на сервере могут значительно быстрее парсится.

PHP скрипты, расположенные на одном сервере, быстро друг с другом взаимодействуют.

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

Тогда расскажу поподробнее. Через это "горло" должны проходить следующие действия:

- регистрация нового пользователя (в ответ - сразу сессия)

- вход (в ответ - сессия)

- изменения данных пользователя (в ответ - данные пользователя после обновления)

- отправка личного сообщения

- чтение личных сообщений

- изменение данных о пользователе и так далее.

На вход этому скрипту поступает массив, например, такого вида

array('function'=>'add_user','name'=>'Роман','email'=>'mail@example.com','pw'=>'blablabla');

В ответ идет JSON например такого вида:

{status:2,erros:{email:'email already exist',pw:'password is too short'}}

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

array('function'=>'add_user','name'=>'Роман','email'=>'mail@example.com','pw'=>'blablabla');

{status:2,erros:{email:'email already exist',pw:'password is too short'}}

Скрипту на стороне клиента Вы не можете запретить ничего! То есть никто не помешает условно хакеру подменить скрипт (js) и отправлять все, что угодно. Данные обязаны проверяться на сервере каждый раз при получении их от клиента.

Рамарио, горло это называется API.

Обычно, для всего этого выделяется определенный роут, например:

api.domain.ru/v1/

Далее, задаем постфиксы для обработки каждой части:

user/auth/

user/reset/

user/logout/

user/get/



post/add/

post/get/

Ваш код при получении запроса по адресу

api.domain.ru/v1/user/get/1/

Должен загрузить информацию о пользователе с ID = 1

Там же можно проверить по заголовкам, авторизован ли пользователь для данной операции.

Можно конечно JSON лить в одну точку, например domain.ru/api/v1/, но архитектура шаткая получается.

Так я описываю скрипт на стороне сервера. Он все проверяет и никакой бяки не допускает.

Пока что вы дошли только до Front Controller

А у MVC все таки есть и модели и вьюхи. На самом деле у вас смешались в кучу люди-кони.

То что вы хотите сделать называеться RESTFull архитектурой, или по другому сервис-ориентированная архитектура. Тогда бэкенд у вас выступает в роли источников данных, а фронтед являеться собственно приложением. Паттерны используют архитектурные реализации конкретного приложения. То есть у вас и на бэкенде может быть MVC и на фронте так же. И обычно MVC это просто разделение полномочий. То есть у вас есть Модель с бизнес логикой, есть Вьюха для отображение этой логики и Контроллер для того чтобы все это дело подружить между собой. Но на одной MVCдалеко не уедешь, в приложениях еще с десяток паттернов нужно заюзать для нормальной архитектуры :)