defenestrator 26 дек 2010 в 14:02

PHP, JavaScript, RPC и другие страшные слова

8 мин

7.9K

PHP*

Из песочницы

Комментарии 28

VolCh 26 дек 2010 в 14:23

>Для подобных систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!

По-моему, ничем не противоречит ваша концепция концепции MVC, вы просто выносите часть VC и часть интерфейса к M на клиента. По крайней мере, если приложить некоторые усилия, то JavaScript код можно будет разделить на V и C, а также интерфейс к M

defenestrator 26 дек 2010 в 14:33

Я с вами не согласен. Так, с большой натяжкой, так можно под MVC подтянуть любую конструкцию.

VolCh 26 дек 2010 в 14:49

Выделение слоя модели у вас налицо, функцию log вполне можно считать вьюшкой (она абстрагирует вывод от остальной программы), всё остальное — контроллер (взаимодействие между моделью и вьюшкой) ;)

defenestrator 26 дек 2010 в 15:02

Хорошо, я объясню, почему я с вами не согласен. Основная разница в терминах и сущностях при помощи которых можно описать и вести разработку. В MVC вы будете строго разделять модель данных от внешнего вида и от обработки данных, что вполне естественно. В нашем же случае мы работаем на уровне взаимодействия интерфейсов. JavaScript программист вполне может быть не в курсе реализации того, что он использует, да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).

В частном случае, конечно, можно подвести эту систему к MVC, но на практике ее возможности гораздо шире. Разрабатывая проект таким способом вы, по сути, сразу же получаете готовое RPC API для его внешнего использования другими приложениями\проектами, чего очень трудно добиться при других схемах разработки.

SMiX 26 дек 2010 в 16:07

Почему это трудно?
И чем вам REST не угодил?

VolCh 26 дек 2010 в 16:08

Так в идеальном MVC взаимодействие осуществляется по интерфейсам, о внутреннем устройстве модели или вьюхи контроллер не знает, а они друг о друге даже не подозревают. А данные всегда хранятся, передаются и возвращаются в каком-то формате, не могут быть «просто данные» в информационной системе, какой это формат JSON, HTML или какой-то бинарный — не суть, особенно при наличии средств инкапсуляции (например нативная поддержка каких-то типов данных в ЯП).

MVC, имхо, не ограничивает возможности никак, она лишь описывает возможную (и во многих отношениях удобную) архитектуру реализаций этих возможностей. Нормальный фреймворк позволяет реализовать классические протоколы RPC с минимальными затратами, а уж вопрос формата представления возвращаемых данных (XML, HTML, JSON, plain tetx, ...) вообще не должен стоять

defenestrator 26 дек 2010 в 21:04

Будь по вашему — пусть это будет MVC. Тем не менее, речь в статье не о дизайне конечного приложения, а о способе взаимодействия кода внутри него.

VolCh 26 дек 2010 в 22:16

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

sndl 26 дек 2010 в 14:49

>Таким образом, я даже не знаю что за модель получилась, но это скорее толстый клиент уже, а не MVC

По-моему эти термины [толстый клиент, MVC] являются вполне непротиворечивыми.

sndl 26 дек 2010 в 14:50

Сорри за небольшое дублирование первого коммента…

defenestrator 26 дек 2010 в 15:02

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

sndl 26 дек 2010 в 15:22

> В нашем же случае мы работаем на уровне взаимодействия интерфейсов.
Противоречия нет

> JavaScript программист вполне может быть не в курсе реализации того, что он использует,
Противоречия нет

> да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).
Тут уже даже не совсем классический толстый клиент получается. Но противоречивости терминов MVC и Thick Client я все равно не вижу.

Так что конкретно мой комментарий вы ничуть не опровергли. Или у меня с логикой не все впорядке, что вполне возможно в день рождения :)

defenestrator 26 дек 2010 в 21:10

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

colonel 26 дек 2010 в 15:22

> impl/TestUser.inc
Не рекомендуется так скрипты называть.
Лучше *.inc.php

Nutochka 26 дек 2010 в 15:31

А ещееё лучше — выносить их поверх корня и не нервничать из-за названий. ;)

defenestrator 26 дек 2010 в 15:33

Спасибо, я учту.

NeX 26 дек 2010 в 15:59

Возможно, вам будет интересна еще эта технология: habrahabr.ru/blogs/Jaxer/

Vladson 26 дек 2010 в 16:04

>>> выбор был не велик
Выбор был ???

Даже если и был, то «PHP-быдлокодинг»-а среди вариантов быть не должно!!!

Он необходим в скоростной разработке (прототипы, презентации, и.т.д.) а в обычной разработке нет такой буквы!!!

serega011 26 дек 2010 в 16:11

Спасибо, мне лично было интересно, а может и пригодится когда. Да, заметил пару опечаток: "(назовем его для приличия aip/Test.php)" и «систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!»

zarincheg 26 дек 2010 в 16:44

В extJS есть классная штука — DataProxy и его расширение HttpProxy, которая, в том числе, позволяет делать удобную обработку действий со Store. А то у вас я так понял какой-то свой объект rpc и ServiceProxy, думаю раз уж extJS решили использовать, то стандартные средства сподручней будут.

kibitzer 26 дек 2010 в 17:38

Автор статьи вроде как Qooxdoo решил использовать. А в extjs есть более близкая «технология», имхо, к тому, что в статье описано — Ext Direct.

defenestrator 26 дек 2010 в 21:15

Работают ли эти системы с сессиями и позволяют ли разграничивать права доступа к объектам на уровне вызовов их методов?

zarincheg 27 дек 2010 в 10:29

Что мешает создать объект, наследуемый от HttpProxy или Direct и добавить туда контроль доступа? Последний я правда не использовал, пока не знаю как там что.