Потому что на каждое действие свой контроллер. А сколько он будет юзать моделей и вьюшек - его личное дело. Просто у тебя эти самые модули - это есть контроллеры. А, то, что называется главным контроллером - это роутер. ZendGuard купите Ну или если все так плохо, то пора переползать на java. Об ООП можно забыть на сайте из двух-трех сотен строчек. Все затраты окупаются архитектурой и акселератором типа ZendGuard. И главное, чтобы
Скорее это диспетчер А для работы с url'ами он использует роутер. по крайней мере, в моём понимании это так
Диспечер, контроллер, какая ф попу разница. Это просто большой switch PHP: <?php if (!array_key_exists($session['auth'])) { switch (PAGE) { case '': module('News', CENTER_SUB); // Список новостей на главной break; case 'news': module('News', CENTER); // Весь список новостей break; // Всё, что можно видеть без авторизации default: module('Authorize', CENTER); // Сперва авторизация break; } } else { switch (PAGE) { case '': module('User', CENTER_SUB); // Выводит общий краткий блок профиля на странице module('News', CENTER_SUB); // Список новостей на главной break; case 'news': module('User', CENTER_SUB); module('News', CENTER); // Весь список новостей break; case 'user': module('User', CENTER_SUB); module('User', CENTER); // Профиль пользователя break; // Всё, что можно видеть под авторизацией default: forward(); // Нефиг вводить чушь, топай на главную } }
Тоже хорошее название. Короче, это такая штука, которая решает, кому отдать управление А реализация не имеет значения
У меня как-то так сделано PHP: <?php // ... $router = new RewriteRouter(); $router->addRoute(new Route('/news/(\d+)', 'news', 'view', array('id'))); $router->addRoute(new Route('/news/editors/', 'news', 'list', array('type' => 1))); $router->addRoute(new Route('/news/users/', 'news', 'list', array('type' => 2))); // ... $dispatcher->setRouter($router); $dispatcher->dispatch($request->getUri()); Стандартный формат для каждого роутера свой. Например, /news/view/id,123/. Все нестандартные форматы uri добавляются через addRoute. По мне так удобно
Sergey89 интересно у тебя сделано, у меня попроще PHP: <? // [url=http://site.com/showforum/byid_3]http://site.com/showforum/byid_3[/url] Rewriter::Run(array("slt"=>"_","st"=>".html","stl"=>"/")); Rewriter::AddType(array("act","method")); if(Rewriter::$get['act']){ /* .... */ if(Rewriter::$get['method'][0]) /*...*/ } ?>
Sergey89 У меня соответствие запрошенного url и пути до контроллера, т.е. для /news будет вызван контроллер Controller_News, в котором уже в конструкторе методами setRoute(регулярка, имя метода) делается то же, что и у тебя. Вызываемому методу в качестве аргументов передаются результаты третьего аргумента preg_match, т.е. то, что в регулярке в скобках. Иерархия контроллеров тоже присутствует, т.е. /forum/users/topusers вызовет контроллер topusers, а если его нет, то users, если и его нет, то forum, ну а если и он отсутствует, то вызовет контроллер, назначенный главным (он же вызывается при корневом пути). В конструкторе главного опять же через setRoute можно все отловить. Как-то так.
Ну и автолоад сделан так, что по имени класа Controller_Forum_Users загрузит файл из controller/forum/users.php
У меня на каждое действие определён Action класс PHP: <?php class NewsPostAction extends Action { public function doGet() { // показали форму } public function doPost() { // сохранили результат } } Чтобы не вводить ещё один промежуточный уровень между экшеном и диспетчером я заранее определяю все возможные варианты роутинга.
а может ли быть "связка" контролеров? например отдельные контролеры страницы и отдельный для товара. и контролер страницы передает управление контролеру товара и потом следующему (той же меню) по очереди, то есть контроллерам всех размещенных внутри страницы моделей, а потом каждый из этих контроллеров точно так же передает управление всем вложенным в него и т.д. пока не будет обработана самая мелкая модель, которую уже не на что разложить. Или на всю страницу обязательно должен быть один контроллер, который отвечает за все- все действия на странице?
зачем? и зачем модели раскладывать? модель - это все необходимое для работы с тем или иным объектом. не надо ее раскладывать.
Буду говорить примерами. Есть модель Сотрудкик. Она имеет: - путь в дереве объектов - фамилию - имя - очество - должность - 3 телефона - кабинет - майл - йску - день рождения она умеет: - сохраняться в базе и оживать от туда - вести в базе лог своих изменений и перемещений в дереве - отослать на свой ящик почту, йсук - по своему пути определить организацию в которой работает - возвращать ФИО ИОФ и ИОФ сокращенно - определить корректность заполнения своих полей Это модель, насколько я понимаю,потому что тут ни слова про отображение и взаимодействие с пользователем. Эта модель используется в десятках случаев в разных местах комплекса. Но интересно вот что: в трех случаях - при создании нового такого экземпляра - редактировании - импорте она взаимодействует с пользователем одинаково. три картинки чтоб нагляднее было. Так вот, чтобы в контроллерах этих трех страниц не переписывать один и тот же кусок кода, мне удобнее создать отдельный Контроллер сотрудника, который отвечает только за сотрудника и передавать ему управление из разных страниц. Что какие преимущества это дает. Я могу вставить эту модель на любую страницу, или к примеру такую страницу вложить в другую страницу как панель, а ее вложить в другую страницу или как угодно. И не придется для каждого такого случая, писать большой контроллер страницы, потому что сотрудник будет обработан своим контроллером, когда контроллер страницы передаст ему управление. Это что такое МВЦ, не МВЦ? Если не МВЦ, то как это правильно называется? Я весь комплекс в таком ключе слабал
Модель не должна знать о своем положении в какой либо иерархии. Имхо, у тебя должа быть модель дерева обьектов, которая должна уметь это ИМХО должен делать контроллер. А это вообще должно делать представление. В этом конкретном случае, я считаю, допустимо добавить это специфическое действие в модель, но это неверно с точки зрения ООП.
Даже не хочу это обсуждать. Интересно мнение про иерархию контроллеров. Это МВЦ все- таки или не МВЦ и тогда как это называется?
Какой кусок кода? Вызов одного метода модели? Или двух? Это не MVC. От MVC тут отличие в том, что функции модели перенесены в дополнительные контроллеры, что влечет за собой необходимость отслеживать в «доп. контроллерах» изменения модели. В MVC сделан упор именно на четкое отделение трех логик и слабое взаимодействие объектов за счет абстракции. Собственно, все мысли Олега верны и модели не должны взаимодействовать друг с другом, хотя и тут есть исключения (абстракция бд, конфигурации и т.п.). Для этого нужно иметь достаточно функциональный шаблонизатор Если интересен только ответ на вопрос «MVC или нет?», то нет.
AlexGousev а между прочим, представление, это не только шаблонизатор. Это вполне может быть какой-то промежуточный слой логики, даже в виде просто кода, выполняющийся перед шаблоницацией.
вы это серьезно? ссылку на первоисточник, пожалуйста, или это собственное заявление? сдается мне вы погорячились
alexey_baranov уважаемый. Это не религия, где "делать надо так, как в книге написано". Это надо думать своей головой и понимать, почему и с какой целью так написано. Модели не должны зависеть от других моделей. Объяснять почему?
для начала уточним один момент. я говорю про "не должны взаимодействовать", а вы говорите "не должны зависеть". это очень разные вещи зависеть и взаимодействовать. объяснять почему? Если вы тоже считаете, что "модели не должны взаимодействовать друг с другом", потрудитесь пожалуйста. интересно послушать