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

12 3
Р
На сайте с 17.05.2011
Offline
136
3250

Начитался я про концепцию MVC, вроде все красиво написано, но я как-то не очень-то вник и начал писать приложение, однако, вот что в итоге получилось:

1) Серверная часть состоит из единственного PHP файла, который POSTом или GETом получает данные, обрабатывает, работает с базой данных и выдает ответ в виде JSON. Вся логика (ограничение доступа, защита данных, валидация, взаимодействие и преобразование данных...) осуществляется именно там. Т.е. расчет на то, что какие бы корявые данные не пришли с запросом ничего плохого с данными не должно произойти.

2) На стороне клиента просто HTML странички обильно приправленные JavaScriptом. Тут вся интерфейсная часть: редиректы со страницы на страницу (в зависимости от ответа сервера), предварительная проверка данных форм, отображение и все такое.

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

К тому же, я так понимаю, что если потом захочется сделать мобильное приложение, это можно будет сделать чуть ли не в несколько кликов с помощью Adobe Phonegap Build (ему просто скармливается клиентская часть приложения - HTMLки - и все готово, выглядит по крайней мере очень просто, хотя, возможно, тут есть нюансы, еще не знаю).

Я понимаю, что я частично лишаюсь навигации через URL, но в моем конкретном случае это вроде и не нужно.

Есть еще какие-нибудь соображения "за" и "против"?

S
На сайте с 30.09.2016
Offline
459
#1
Рамарио:
Серверная часть состоит из единственного PHP файла

Я так понимаю - это далеко не MVC

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

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

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

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

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
M
На сайте с 09.01.2012
Offline
37
#2

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

D
На сайте с 18.12.2015
Offline
142
#3

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

Разработка и поддержка высоконагруженных проектов.
Р
На сайте с 17.05.2011
Offline
136
#4
danforth:
Поздравляю, вы открыли SPA. Минусы - скорость разработки. Плюсы - скорость работы. Паттерн, скорее всего, MVVM. Только в стадии зародыша.

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

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

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

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

D
На сайте с 18.12.2015
Offline
142
#5

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

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

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

Р
На сайте с 17.05.2011
Offline
136
#6
danforth:
Про данные через одно место, слишком мало инфы вы дали, чтобы сказать вам, хорошо вы придумали, или плохо.

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

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

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

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

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

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

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

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

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

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

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

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

AP
На сайте с 12.06.2015
Offline
75
#7
Рамарио:
Тогда расскажу поподробнее. Через это "горло" должны проходить следующие действия:
- регистрация нового пользователя (в ответ - сразу сессия)
- вход (в ответ - сессия)
- изменения данных пользователя (в ответ - данные пользователя после обновления)
- отправка личного сообщения
- чтение личных сообщений
- изменение данных о пользователе и так далее.
На вход этому скрипту поступает массив, например, такого вида
array('function'=>'add_user','name'=>'Роман','email'=>'mail@example.com','pw'=>'blablabla');

В ответ идет JSON например такого вида:
{status:2,erros:{email:'email already exist',pw:'password is too short'}}

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

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

D
На сайте с 18.12.2015
Offline
142
#8

Рамарио, горло это называется 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/, но архитектура шаткая получается.

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

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

Aisamiery
На сайте с 12.04.2015
Offline
206
#10
Рамарио:

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

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

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

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

Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
12 3

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий