Это как? Без 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 - это все же клиент-серверная технология! Или вас напрягает слово - "технология"? Если так, то хорошо, не технология, а подход! 

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