Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
>Для подобных систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!
По-моему, ничем не противоречит ваша концепция концепции MVC, вы просто выносите часть VC и часть интерфейса к M на клиента. По крайней мере, если приложить некоторые усилия, то JavaScript код можно будет разделить на V и C, а также интерфейс к M
По-моему, ничем не противоречит ваша концепция концепции MVC, вы просто выносите часть VC и часть интерфейса к M на клиента. По крайней мере, если приложить некоторые усилия, то JavaScript код можно будет разделить на V и C, а также интерфейс к M
Я с вами не согласен. Так, с большой натяжкой, так можно под MVC подтянуть любую конструкцию.
Выделение слоя модели у вас налицо, функцию log вполне можно считать вьюшкой (она абстрагирует вывод от остальной программы), всё остальное — контроллер (взаимодействие между моделью и вьюшкой) ;)
Хорошо, я объясню, почему я с вами не согласен. Основная разница в терминах и сущностях при помощи которых можно описать и вести разработку. В MVC вы будете строго разделять модель данных от внешнего вида и от обработки данных, что вполне естественно. В нашем же случае мы работаем на уровне взаимодействия интерфейсов. JavaScript программист вполне может быть не в курсе реализации того, что он использует, да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).
В частном случае, конечно, можно подвести эту систему к MVC, но на практике ее возможности гораздо шире. Разрабатывая проект таким способом вы, по сути, сразу же получаете готовое RPC API для его внешнего использования другими приложениями\проектами, чего очень трудно добиться при других схемах разработки.
В частном случае, конечно, можно подвести эту систему к MVC, но на практике ее возможности гораздо шире. Разрабатывая проект таким способом вы, по сути, сразу же получаете готовое RPC API для его внешнего использования другими приложениями\проектами, чего очень трудно добиться при других схемах разработки.
Почему это трудно?
И чем вам REST не угодил?
И чем вам REST не угодил?
Так в идеальном MVC взаимодействие осуществляется по интерфейсам, о внутреннем устройстве модели или вьюхи контроллер не знает, а они друг о друге даже не подозревают. А данные всегда хранятся, передаются и возвращаются в каком-то формате, не могут быть «просто данные» в информационной системе, какой это формат JSON, HTML или какой-то бинарный — не суть, особенно при наличии средств инкапсуляции (например нативная поддержка каких-то типов данных в ЯП).
MVC, имхо, не ограничивает возможности никак, она лишь описывает возможную (и во многих отношениях удобную) архитектуру реализаций этих возможностей. Нормальный фреймворк позволяет реализовать классические протоколы RPC с минимальными затратами, а уж вопрос формата представления возвращаемых данных (XML, HTML, JSON, plain tetx, ...) вообще не должен стоять
MVC, имхо, не ограничивает возможности никак, она лишь описывает возможную (и во многих отношениях удобную) архитектуру реализаций этих возможностей. Нормальный фреймворк позволяет реализовать классические протоколы RPC с минимальными затратами, а уж вопрос формата представления возвращаемых данных (XML, HTML, JSON, plain tetx, ...) вообще не должен стоять
>Таким образом, я даже не знаю что за модель получилась, но это скорее толстый клиент уже, а не MVC
По-моему эти термины [толстый клиент, MVC] являются вполне непротиворечивыми.
По-моему эти термины [толстый клиент, MVC] являются вполне непротиворечивыми.
Сорри за небольшое дублирование первого коммента…
Я выше ответил, почему я так считаю.
> В нашем же случае мы работаем на уровне взаимодействия интерфейсов.
Противоречия нет
> JavaScript программист вполне может быть не в курсе реализации того, что он использует,
Противоречия нет
> да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).
Тут уже даже не совсем классический толстый клиент получается. Но противоречивости терминов MVC и Thick Client я все равно не вижу.
Так что конкретно мой комментарий вы ничуть не опровергли. Или у меня с логикой не все впорядке, что вполне возможно в день рождения :)
Противоречия нет
> JavaScript программист вполне может быть не в курсе реализации того, что он использует,
Противоречия нет
> да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).
Тут уже даже не совсем классический толстый клиент получается. Но противоречивости терминов MVC и Thick Client я все равно не вижу.
Так что конкретно мой комментарий вы ничуть не опровергли. Или у меня с логикой не все впорядке, что вполне возможно в день рождения :)
> impl/TestUser.inc
Не рекомендуется так скрипты называть.
Лучше *.inc.php
Не рекомендуется так скрипты называть.
Лучше *.inc.php
Возможно, вам будет интересна еще эта технология: habrahabr.ru/blogs/Jaxer/
>>> выбор был не велик
Выбор был ???
Даже если и был, то «PHP-быдлокодинг»-а среди вариантов быть не должно!!!
Он необходим в скоростной разработке (прототипы, презентации, и.т.д.) а в обычной разработке нет такой буквы!!!
Выбор был ???
Даже если и был, то «PHP-быдлокодинг»-а среди вариантов быть не должно!!!
Он необходим в скоростной разработке (прототипы, презентации, и.т.д.) а в обычной разработке нет такой буквы!!!
Спасибо, мне лично было интересно, а может и пригодится когда. Да, заметил пару опечаток: "(назовем его для приличия aip/Test.php)" и «систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!»
В extJS есть классная штука — DataProxy и его расширение HttpProxy, которая, в том числе, позволяет делать удобную обработку действий со Store. А то у вас я так понял какой-то свой объект rpc и ServiceProxy, думаю раз уж extJS решили использовать, то стандартные средства сподручней будут.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP, JavaScript, RPC и другие страшные слова