Добрый вечер, Дорогие форумчане!

Столкнулся с неудобством подхода MVC и динамики, реализованной, например, ajax.
Дело в следующем: если есть устоявшаяся структура (а MVC как раз это предполагает), но хотелось бы сделать, например, удаление на лету сообщений. Для этого было бы гораздо удобнее сделать отдельный файл php со скриптом и с помощью функции ajax обращаться к нему.. Ну тут неувязочка... тот скрипт ни чего не знает о БД, о константах, которые используются.... т.е. придется все туда подключать... а через include иногда это невозможно... если например работаем с captch'ей. В общем, хотелось бы узнать у тех, кто работает в MVC, каким образом они делают подобную динамику.

Заранее большое спасибо всем! =)

А причем тут MVC и ajax?

Одно другому никак не мешает.
Вызывайте через ajax свой контроллер и пусть он обращается к модели за удалением сообщения.

AGENTxXx, при обращение через AJAX, в глобальной переменной $_SERVER появляется новое значение

вот по ней и смотрите как надо отдать ответ. А обращение оставьте по старому (через <a href="url">link</a>), просто повести обработчик на JS. Это позволит избежать проблем, когда у клиента отключен JS 

Можно почитать про вещь, которая в контексте ZF называется contextSwitch. И реализовать у себя аналог.

Fortop - в данном случае так и делал! Но считаю не очень эт удобно..
Ну раньше без MVC кода прогал, то было удобнее, через JS вызывал и все ок! А тут - придется к контроллеру опять обращаться.. Ну в общем понял, что все видно так и делают.

MoLeX - на счет - JS и href - спасибо. Что т в последнее время.. да и вообще так не делал))) Я обходился как то noscript и в нем замечанием)))

Aliance - хорошо, посмотрю. Может это именно то, что нужно! =)

Вообще-то MVC для того и придуман, чтобы все так делали  

ksnk - в MVC ни чего не говорится о динамическом взаимодействии (ну где я читал, точно). А для каждого подхода - есть и свои хитрости. Это точно также, как MVC применили к PHP частично ущемляя подходы в стиле ООП - применяют в основном MVC для процедурного подхода в PHP

А при чем тут, извините, динамическое взаимодействие? Принцип хоть при динамическом, хоть при статическом, остается один и тот же - представление обращается к контроллеру (в данном случае). А как оно это делает (через пост, гет, аякс, мысленно) - это уже не парадигма MVC. Суть остается сутью. 

Пожалуйста, не говорите ерунды. Никто ничего ни к чему не применял. Вы о чем вообще?

AGENTxXx, 


Гммм ... MVC всего лишь структурное расслоение системы, а как использовать тот же слой служб контроллеров уже зависит от разработчика. Фактически и в основном, в этой модели, контроллеры являются службами содержащими сценарии, почему и называются контроллерами сценариев. Но если сам метод будет очень "тонким" и будет содержать только логику управления, соответственно вся бизнес-логика ляжет на предметную область, тогда будет ООП "чистым", иначе, чем "толще" контроллер со сценарием, будет превращаться больше в процедурную (сценарий транзакции или табличный модуль, скорее всего последнее) схему в методе. 
Опять же для каждой задачи свой принцип лучше.

AGENTxXx, 


Да, это так, но только при одном условии, если слой View со своей бизнес логикой находится в основном на клиенте. Тогда удобней модель FrontController и PageController.
 Хотя в принципе можно построить любую схему только на основе слоя служб в виде контроллеров сценариев, бизнес-логики (например Strategy) и слоя данных (например на основе шлюзов данных или ещё лучше ActiveRecord + Gateway).

Добавлено @ 17:02


Этим как раз занимается слой служб ApplicationController.

Это сообщение отредактировал(а) Sentox - 17.5.2012, 17:05

Guedda, 


Если клиент (например на JS или на JAVA) содержит логику слоя представления и некоторую часть бизнес логики, смысл в MVC для сервера пропадает, да же становится не удобным и не нужным.

Это сообщение отредактировал(а) Sentox - 17.5.2012, 17:21

это не смысл в MVC пропадает. Это вы нарушили его парадигму.

Хммм .... вообще то я о построении архитектуры изначально. 
Если клиент "толстый" то MVC на сервере несостоятельно в этом контексте.  Впринципе довольно несложно рефакторить систему из MVC, если потребуется переход на толстый клиент. Сам принцип переноса слоя представления на клиент уже делает часть View на сервере просто ненужной и не используемой.

Это сообщение отредактировал(а) Sentox - 17.5.2012, 21:46

Во-первых, у вас 1но приложение, а не два разных.
Во-вторых, все веб приложения в той или иной степени переносят слой представления на клиент, что ничуть не опровергает архитектуру MVC.

В-третьих



Вы уж определитесь, то ли MVC у вас становится ненужным как архитектура, то ли view 

Guedda - не совсем понял ваше цитирование моих слов! Я с ними полностью согласен. MVC - для ООП, а в php часто пользуются процедурным подходом применяя MVC!

Так что давайте по делу! Есть ли те, кто не через контроллер делает, а другим подходом? =)

P.S. Ребята, я понимаю что вы все хотите помочь, но основной вопрос все же был - как сделать удобнее динамические обращения. Ну вот смотрите: есть у нас контроллер, к которому мы должны обратиться и он пошлет нас по адресу. Ну а контроллер весит например 500 кб, а нужная нам часть - всего 10 кб. В итоге затраты 490 кб лишних... В общем - то ли тех, кто на MVC и с динамикой - все устраивает, то ли я чтот не так делаю..... 

Это вообще то часть архитектуры MVC, для чего я и пишу на английском а слой представления указываю как абстракцию.



Вы наверное немного недопонимаете концепцию слоёв и уровней. Слой системы может находится на физическом уровне клиента.
Я ж специально привёл примеры его программирования на других языках. Допустим тот же слой представления (часть View от MVC) будет на клиенте реализован в JS, тогда часть View просто не используется в этой архитектуре на PHP. И это всё 

Пример: есть толстый клиент написанный на JS и выполняет полностью логику представления (шаблонизация)(кстати ещё лучше пример с пользовательскими скриптами для браузеров). Используя YII (MVC) уровень представления почти не используется только активно учавствует Controller<->ModelData. На сервере только хранятся шаблоны html, которые использует JS на клиенте. Тот же эффект и на клиенте JAVA да же со своими окнами но шаблоны в другом формате.

Это сообщение отредактировал(а) Sentox - 17.5.2012, 22:59

  
Это как? Без MVC? 

эм. что именно весит - готовый ответ или исполняемый код?

Это сообщение отредактировал(а) MoLeX - 18.5.2012, 09:03

Неправильно организовано приложение.
Осуществите декомпозицию. Вероятно у вас там смешаны в кучу и модели и несколько контроллеров.



Вот сейчас мы и разберемся, кто недопонимает.


MVC как парадигма не зависит от языка.
Более того, MVC вполне свободно ложится на архитектуру клиент-сервер.

А вот тот факт, что вы ваше приложение не в состоянии воспринять как единое целое и ожидаете обязательного наличия реализации View на сервере показывает ваш уровень понимания MVC как архитектуры.

Тем не менее, MVC не единственная парадигма (просто в условиях публичного web наличие толстых клиентов редкость).
Существует еще к примеру multi-tier архитектура.
Только это не ваш случай.

P.S. А есть еще и MVP, почитайте и о нем тоже.

Что т я уже сам запутываюсь.

ksnk - думаю да, тут с этим может быть придется выйти за рамки

MoLeX - не совсем понял, что не так =)

Давайте опишу лучше то, как у меня организована связь, а вы меня покритикуете!
1. В модели есть функция, например, удаления новости.
2. Также в модели есть функция формирования новостей, которая вызывается в VIEWе
3. В Контроллере осуществляется подключение всех необходимых файлов: Переменных, файл конфига, файл БД, стандартные функции обработки, стандартные функции отображения.
4. Ajax функция - в отдельном js файле и подключается в файле index.php
5. При нажатии на кнопку удалить, я отправляю запрос controllerу, контроллер, по GET параметру находит, что такую то новость надо удалить и вызывает из модели функцию удаления.
6. Функция возвращает true или false.
7. Далее контроллер прерывается с помощью функции exit().
8. Конец =)

Кто может сказать, каким образом можно подлатать? Может быть выделить спец. контролл и модель, которая как раз будет заниматься динамикой => в контролле не будет лишней информации, а в запросе ajax добавится новый параметр, который как раз укажет, из какой, например, таблицы нужно удалять... и засунуть может все это в папку libs)))

AGENTxXx, опечатался. 

Насколько Вы здесь описали, я понимаю, вы путаете понятия моделей и контроллеров. А если не путаете, значит Вы полностью нарушаете парадигму MVC. Представление не должно обращаться к модели, а контроллеры не должны инициализировать БД.

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

MoLeX - видно не совсем удачный пример привел! Я говорил про исходный код! 
Да, можно утверждать, что такого быть не может и значит что то сделано не правильно... но всякое ведь бывает... Подключаемые файлы могут спокойно исходный код до 500 кб догнать - это мое мнение!

Guedda - эм... Как я читал и смотрел, модель должна содержать функции для работы, контроллер - управление этими функциями, вью - отображение информации... Где здесь опечатка? Или что не правильно я понял?


Может кто нибудь дать хорошую ссылку на MVC - чтобы все же правильно все сделал... Видно я что то не допонимаю(((   Ну а то, что некоторые считают как раз нормальный вариант: "Можно сделать отдельный контроллер с методами, с которыми будет работать только аякс" - в общем, этот подход меня устраивает. Киньте ссылку плиззз, и можно тему будет закрыть! Всем большое спасибо!!!   

Модель описывает данные (таблицу, допустим) и содержит функции непосредственно с этими данными. Контроллер, в свою очередь, является связующим звеном между моделью и представлением (вставляет данные из модели в страницу (представление) - если примитивно говорить).
А у тебя получается, что представление обращается непосредственно к модели (как я понял) - а это неправильно.


Как я понимаю, тебе необходима ссылка на страницу, где рассказывают о MVC? Для начала (особенно внимательно вчитайся в раздел "Концепция").

  Я всё время показывал что наоборот View не обязателен при реализации его на клиенте



Это понятно, только разговор про серверную часть. Если на сервере Controller<->Model а на клиенте View - это не есть MVC, никак.
Почему, я объясню. 
Потому как клиент может содержать и примитивную бизнес-логику по работе с данными минуя controller-model обращаясь непосредственно к данным, это во многих случаях оправдано. Да и тот факт, что следует применять концепцию паттернов (а MVC есть паттерн) в пределах одного физического уровня, указывает на то что это опять же не MVC, если слой представления перенсён на другой физический уровень. 
Отсюда следует что концепция слоёв и уровней это не то же самое что накладывание паттернов на одно приложение, если они да же распределены удалённо. Это очень усложняет систему и её поддержку. Применение паттернов должно быть применено в пределах одного физического уровня иначе система будет слишком жёсткая и связная.


Читаем мой пост выше про служебные слои, стратегии и модели данных.



Это совершенно отдельный разговор распределённых систем, сюда вообще не входит.


Тем не менее есть, я такую уже делал. У меня на клиенте был реализован паттерн MVC ! 
Кстати пример такой системы - это gmail почта.

С уважением 

Это сообщение отредактировал(а) Sentox - 18.5.2012, 13:46

Разве? 

http://en.wikipedia.org/wiki/Model%E2%80%9...80%93controller

Добавлено через 6 минут и 7 секунд

У вас какой-то сторонний клиент вне вашего приложения?  
И при этом знает что-то о вашем приложении?
Покажите мне такой.



Где?


Аякс у нас теперь серверная технология? Да вы гуру!  

 

Он малость ужасен.




Кто-нибудь понял что тут пытались сказать?


Можно этимологию этого термина? Я несколько не понимаю что вы хотите сказать.

Добавлено через 7 минут и 30 секунд

Каких еще распределенных систем?   

Разве. Графическое представление MVC - везде и всегда:


Видите стрелку Model->View?

Для меня Стив Барбек (?) не является "отцом" MVC и я привык доверять нескольким источникам сразу, а не словам какого-то незнакомого мне человека.

Fortop, 


Наверное я поспешил что то показывать, ну ок.
К Фаулеру и Мартину стоит обратится за помощью.  тогда можно будет о чём то общаться.
"Шаблоны корпоративных приложений" (М. Фаулер) , одно из лучших пояснений MVC да вообще очень хорошо расписан механизм построения архитектуры приложений и концепции расслоения системы.

Ах да, по поводу сценариев ещё стоит познакомится с UC UML



Ещё раз, gmail почтовик можно посмотреть.
Клиент знает о приложении только по его API, что делает его переносимым и не связным.
API закладываются в url ajax запросов

Это сообщение отредактировал(а) Sentox - 18.5.2012, 15:00

Это уже потянет холивар.
Допустим в YII реализован MVC с доступом модели представления к модели данных, иногда это более чем нужно. 
Если не предоставить модели представления доступа к модели данных и наоборот получим более толстую модель контроллера, который должен обеспечить синхронность данных меду ними и взять на себя обязанность в этом. Я впринципе противник такой модели, считаю что контроллер должен заниматься только управлением и передачей моделеи представления к модели данных, что соответственно добавляет стрелку на рисунке между моделями.
Опять же повторюсь это холивар , и для каждой задачи свой подход наиболее удобен.

В завершении 
MVC как и все паттерны не жёсткая парадигма, которая должна управлять разработчиками, наоборот она может гибко изменяться (как и все паттерны) взависимости от задач поставленных бизнеc-логикой, но не наоборот.

Это сообщение отредактировал(а) Sentox - 18.5.2012, 14:42

Guedda, у Фаулера я не встречал упоминания об ограничении обращения представления к модели.
Вы можете привести источники где это указано?

И, да, обычно ваша схема MVC дополняется как минимум пунктирной связью модель-представление 
http://java.sun.com/blueprints/patterns/MVC-detailed.html
это достаточно авторитетный для вас источник? 

Guedda - спасибо, почитаю там


 - с этим согласен =)



 - видно я не знаю еще про технологию, которая неведанным образом передает ajax скрипт с сервера клиенту... Как еще другим образом из того, что я сказал можно было понять, что ajax - это серверная технология я не знаю..... Я бы сказал, что Ajax - это все же клиент-серверная технология! Или вас напрягает слово - "технология"? Если так, то хорошо, не технология, а подход! 

Из кучи информации, полезным в постах оказалась - ссылка и изображение! 

Достаточно  Спасибо за ссылку, почитаю. 

Вот не гуру UML  что такое UC? 
use case? И с каких дел вы его сюда примешиваете?


Хорошо  я подожду.
Как осилите его. Пообщаемся 


Ох, какие сложности с прочтением моих вопросов.
Думаю срок на изучение Patterns of Enterprise Application Architecture вам надо утроить.
 
Я спрашивал про сторонний клиент.
Что в gmail стороннего?

Добавлено через 3 минуты и 59 секунд

Он в опкод кешере. Поэтому это вас не должно волновать.

Плюс autoload позволяет подгружать лишь то, что действительно используется.
Если, конечно, у вас проведена декомпозиция и нет монстроузных классов.

Добавлено через 14 минут и 32 секунды

Это было не вам 
Это из высказываний Sentox следовало.

MVC лишние в PHP хуеву тучу времени отнимает при  доработке напилиного не одним месяцем работы, вполне достаточно
autoload + годами наработанные полезные функции, класс синглитон для PDO, гибкий собственный mod-rewrite или как у меня настраивается через веб интерфейс

Fortop, 


Если Вы хорошо знаете Фаулера, стоило бы знать его предпочтения в терминологии.
"Шаблоны корпоративных приложений" (Фаулер) часть 1. Обзор, гл. Уровень служб, стр.57



Осиливайте  
C растущим уважением!

Это сообщение отредактировал(а) Sentox - 18.5.2012, 21:51

Точно стоило бы знать? 

Даже в форме такого искажения? 



Где ваша терминология и где Фаулер? 

Вот вам еще образчик  вашего понимания

И сравните с описанным тут 
http://java.sun.com/blueprints/patterns/MVC-detailed.html

Про UC UML я ответ услышу? Я действительно не понимаю о чем вы пытались мне сообщить 
Или это опять ваша трактовка вот этого?


Это сообщение отредактировал(а) Fortop - 18.5.2012, 23:33

Fortop, 


Я рад что Вас рассмешил 
Значит на это позитивной для Вас ноте завершим дискуссию.
Как говаривал дядюшка Боб (Роберт Мартин), если дискуссия длится более получаса (в нашем случае три страницы   ) с совершенно бесполезным результатом лучше её закончить.

С уважением к Вам, без сарказма, не принимайте это как подкол.