Хотел бы поднять такую тему. Как вы считаете в модели MVC какой функционал должен реализовывать View, а какой Model или Controller. Например, мне не совсем понятно до конца такой момент. Количество объектов на страницу, при реализации пэйджера - это забота вида или модели. Вроде как бы этот параметр больше относиться к виду, но вот реализуется то зачастую он именно в модели, на сколько я знаю. В противном случае, шаблонизатор должен взаимодействовать с моделью в обратном направлении нежели традиционно. Это теоретически может приводить к излишествам. Некторое авторы книг выделяю помимо трех составляющих MVC некую infrastructure - . Может быть это ее обязнности? Как вы считаете?
Вроде бы все довольно четко: данные и представление. Данные отдает модель. Если нужен постраничный ввод, то нужна модель, позволяющая выбирать не целый список, а конкретную его часть. Какую именно? Это решает контроллер, основываясь на переданном URL и параметрах. Представление тут вообще не участвует. А инфраструктура - это роутинг, вспомогательные функции, автолоад, загрузка конфигурации и т.п.
я тоже ломол голову над этим, когда только сел на MVC. Сначала казалось, что это все очень субъективно и зависит от привычек программиста, даже настроения. Интересно, что тогда в начале, один раз разделив функционал между МВС, я мог через день уже перераспределить его по новой. И так по несколько раз. Самый частый вопрос, который появлялся это "вот этот метод относится к модели или к вьюшке?", "а это должна делать модель или контроллер?" и в конце концов пришел к универсальному правилу, которое позволяет однозначно все такие моменты раз и навсегда. Теперь я всегда представляю, как будет работать программа на этих моделях в консольном приложении, даже если она никогда в консоли работать не будет. Это очень просто. Все что там пригодится- это Модель, все что не пригодится- или вьюшка, или контроллер. Ну а вью от контроллера отделить никогда не составляет труда. Иногда получается, что какой- то функционал пополам разделяется между моделью и например контроллером, но всегда однозначно и даже если через месяц мне надо будет что- то подправить, я точно знаю, где надо искать этот кусок кода в модели или контроллере. а вот это я не совсем понял. как это количество объектов? количество объектов никогда считать не надо. сколько получилось, значит столько и надо. приведи пример своей реализации на словах. обсудим.
я еще не сильно отделяю контроллер от вида, поэтому он еще путается с моделью ... Короче дело не в этом. Вопрос в том, где пишется переменная, в которой содержится количество объектов на страницу в коде вида или в коде модели. Если количество объектов это вид(а это вид), то этой переменной в коде модели не должно быть. Логично? Разделение же есть. Допустим она передается туда в качестве параметра вида - значит Может так понятнее вопрос будет?
kostyl, в контролере. Контролер соеденяет модель и вид: вид показывает, модель описывает, а контролер выполняет. PHP: <?php class Pager extends Controller { function show(){ $query = $this->db->fetchOne('select count(*) as `count` from ...'); $this->template->assig('count', $query); $this->template->render('pager'); } } Как-то так. Для отдельных страниц, например, списка анкет чьих-то может быть так: PHP: <?php class FormList extends Controller { function show(){ $query = $this->db->fetchOne('select count(*) as `count` from ...'); $this->template->assig('count', $query); $this->template->render('form/list.html'); } } Контролер передаёт переменную в общий шаблон, там пейджер получает переменную и выводит страницы. Но тогда пейджер должен быть хелпером (фактически это просто статичный метод), а не отдельной сущностью. P.S. Я могу и напутать. В фреймворках которые смотрел так организовано. Вот небольшой список фреймворков, ковыряй их.
Ну обычно на разных страницах нужно получать разное количество объектов, поэтому зашивать число объектов в модель не айс. Например, авторы python фреймвока django, называют его MVT фреймвоком (Model View Template). Слои остаются теме же, что и в MVC, но терминология по моему боле ясной становится. Собственно вид решает что показывать, но не он не знает как надо показывать. Как показывать знает шаблон.
lexa мда тут другой подход нежели у меня... у меня контроллер разделен между браузером и Reactor-ом и шаблонизатор совершенно отдельный, и он не вычисляет номер страницы..., а номер страницы вычислят походу Action Reactor - а..., тогда у меня получается количество страниц относиться к контроллеру... жесть...
количество страниц- это однозначно модель, потому что в консольном приложении можно задать вопрос пажанатору "сколько у тебя сторок?", "сколько строк на страницу?" и т.п. представь себе ситуацию что ты данные из пагера по крону выгружаешь и отсылаешь куда- то по почте. Тут не будет ни вьюшек, ни контроллеров, только модели балакают друг с другом. если ты отдашь функционал, про который пишешь контроллеру, то как ты сможешь реализовать эту задачу? тебе придется или дублировать этот функционал в модели или за уши притягивать контроллер. так что это модель.
а где ты этот код используешь? число объектов на страницу это внешний критерий, который ты передаёшь модели скажем из контроллера.
мда....я так понял надо пересматривать все сущности, раньше я судил своими визуальными органами, тобишь глазами, что должно быть в виде. Оказывается это суждение ложно....
когда я судил своими визуальными органами, что должно быть в виде, то мои визуальные органы каждый день подсказывали мне новые и новые идеи. через каждый день хотелось все переписывать. А хуже всего обстояли дела с наследованием, потому что я сегодняшний уже не помню, что впихнули мои визуальные органы вчера в контроллер, от которого я собираюсь наследовать. Чтобы в этом не запутаться, должно быть какое- то универсальное правило на все- все тройки МВЦ. на "ощущениях" не прокатишь
нет не из контролера. я так про себя рассужнаю. "есть страница, на которой есть пагер точка. эта страница с пагером есть когда есть контроллеры и вьюшки и когда нет никаких там вьюшек. Вообще ничерта нет, даже клавиатуры и дисплея у компьютера нет". Ровно то, что осталось при этом и описываю в моделях: <?php class Pager extends Model{ public $count; } class ExemplePage extends Page{ public $p; //пагер function __construct(){ $p= new Pager(); $p->count= 50; } } Естественно, упрощено для выражения. В другой странице будет $p->count= 20; А потом на это навешиваю вьюшки и контроллеры.
думаю тут важно понимать что такое "количество объектов на страницу", наверно все же за это отвечает контроллер или инфраструктура. За это НЕ отвечает модель, потому что в модель эти данные передаются, и за это Не отвечает вид, так как вид лишь оперирует(отображает) данные из набора, предоставленному ему моделью, не зависимо сколько там объектов... ? При этом также управляет моделью как и должен. Он говорит ей - дай 10 объектов виду, она дает, и всё.
То есть если на другой странице надо будет вывести 20 объектов, то ты создашь для этого новую модель?
Может создам, может не создам. Если количество строк- это все чем отличается две страницы, тогда это лишне. Проще сделать PHP: <?php $page= new ExamlePage(); $page->p->count= 50; для меня модели это классы в консольном приложении где нет никаких МВЦ. спросить буду ли создавать тут новую модель- это то же самое, что спросить, буду ли я создавать в консольном приложении новый класс, если все чем они отличаются- значение одного поля. конечно не буду.
кто их туда передает? по моему их никто туда не передает, а просто устанавливает программист. тут один момент: предположим пользак может сам выбирать, сколько объектов должно отображаться на странице, как вот здесь 10, 20 или 50 http://new.techhome.ru/catalog/byt/181 тогда все равно количество хранит модель, а устанавливает это количество у модели конечно контроллер. то есть все равно сначала инициализируется модель $p->count= 50; а потом если контролер это значение поменяет- хорошо, не поменяет- тоже хорошо так и останется 50 (это случай когда пользак первый раз зашел на страницу). Вьюшка отрисует что получится и все будет хорошо.
2Sergey89 повторю, что всегда, когда думаю о моделях и пишу модели, заставляю себя представлять консольное приложение. даже если это никогда в будущем не будет консольным приложением. потому что в консольном приложении нет отображений и взаимодействия с пользователем, т.е. остается чистая как слеза младенца модель. И сейчас это для меня консольное приложение. А где в консольном приложении можно вызвать кусок кода, чистого от МВЦ? Правильно везде. В абсолютно любом методе абсолютно любой модели. можно просто в файле, который запустится по крону. если страницу пора отобразить, я навешываю на класс страницы вьюшку и получается так. файл examplePage.php PHP: <?php $page= new ExamlePage(); $page->p->count= 50; $pageView= new PageView($page); // это вьюшка получает страницу, которую ей предстоит отобразить $pageView->show();
часто это происходит в контролере. например пользак нажал на кнопку "Выбрать исполнителя", тут должна открыться страница выбора. то что для пользака звучит "открыться"- на нормальном языке звучит так: создается модель страницы, контролер ее инициирует, вьюшка отображает. то есть где то в контролере родительской страницы будет OnOpenSelectPage() PHP: <?php class ParentPageCont extends PageCont{ OnOpenSelectPage(){ здесь весь код из прежнего поста } } но я еще раз хочу сказать, что могу очистить весь код от интерфейса, останутся одни модели и модели будут прекрасно жить самостоятельно. им нежны контролеры только чтобы пользователь мог на них воздействовать и вьюшки только для отображения. если надо отобразить модель в другом контексте, такое часто бывает, я просто навешиваю другую вьюшку. Если как- то по другому надо слушать пользователя, то навешиваю другой контролер, который чаще всего унаследован от прежнего.