Как можно реализовать данного зверя? мой вариант.. но он точно не правильный! помогите советом что нужно переделать.. Код (Text): class Controller { protected $view = array(); // Главный запрос определюющий конечный фаил function Route() { $route = $_GET['route']; // Получаем раздельные части $route = trim($route, '/\\'); $this->view = explode('/', $route); } } class Modul extends View { function Template($skin) { $this->ControlFile(); return 'template' . DIRSEP . $skin . DIRSEP . 'index.php'; } function File() { return $this->modul; } } class View extends Controller { protected $modul; function ControlFile() { $this->Route(); $cmd_path = 'view'; // Поиск пути foreach ($this->view as $part) { $fullpath = $cmd_path . DIRSEP . $part; // Есть ли папка с таким путём? if (is_dir($fullpath)) { $cmd_path .= DIRSEP . $part; array_shift($this->view); continue; } // Находим файл if (is_file($cmd_path . DIRSEP . $part)){ $view = $cmd_path . DIRSEP . $part; array_shift($this->view); break; } else { $view = 'view/404.php'; } } if (empty($view)) $view = $cmd_path . DIRSEP . 'main.php'; $this->modul = $view; } }
пока не поймешь зачем оно и как, лучше не пытаться. пишите как вам нравится, и однажды у вас получится MVC
меня всегда умиляла модель когда классы наследуют друг друга. напрашивается вопрос, а зачем вообще тогда ООП? Вроде бы классовый ООП прежде всего призван экономить пространство имен, а получаем, что контроллер(controller) представление (view) модули (modul) склеиваются в единый класс и возвращаемся опять к тому от чего уходили. единое неэкономичное расходование пространства имен. MVC только с помощью патерна синглтон имеет гибкость. тоесть когда классы глобальны и наследовать их ненужно. Получаем логичноть архитектуры в этом случае во всех смыслах.
Главная ошибка новичков - они считают, что бизнес-логика должна быть везде. В то время как идея MVC как раз выделить бизнес-логику в контроллер, максимально отделив друг от друга представление, бизнес-логику и данные. Нет, View - это могут быть тупо нативные шаблоны, модель - СУБД, а контроллер - вся логика, которая будет подключать шаблоны и получать/записывать данные в MySQL. Вот вам и MVC.
Фееричный бред. Есть только одна причина использовать синглтон - получить фабрику. За остальные нужно отрывать руки. MVC и синглтон имеют друг другу отношение как корова и дождик.
Alex_pac Вроде бы классовый ООП прежде всего призван экономить пространство имен откуда берутся такие безумные идеи? =) ООП призван упростить разработку. Только это и ничего кроме.
Alex_pac MVC только с помощью патерна синглтон имеет гибкость. что ни фраза - то перл! Еще парочка топиков и жемчужный фонд россии переедет в квартиру алекса.
Ну вообще ООП действительно решает многие проблемы, которые возникают когда все переменные в одном неймспейсе. Но решить проблему нехватки пространства имен призваны множественные пространства имен (которые появились в PHP 5.3). Наследование - важнейший инструмент а ООП после инкапсуляции.
Ага, ттук... ну в принципе для небольших проектов как вариант. Т.е. если один товарисч обозвал это тупым и уродливым и даже если при этом он прав - еще не повод бездумно все переделывать. Но в общем ввод service layer бывает удобен.
MiksIr, tommyangelo , друзья, покажите пример правильного с вашей точки зрения сервисного слоя, а то все абстрактно как-то =)
я могу упрощенно рассказать. Например есть модель, которая каким-то своим способом (например через конструктор запросов) работает с таблицей Users Без сервисного слоя мне чтобы выбрать забаненых юзеров прямо в контроллере пришлось бы писать что-то типа $modelUser = new User(); $modelUser->findAll()->where('status = ' . STATUS_ACTIVE); А если эту операцию вынести в сервисный слой, то в контроллере будет что-то типа User::GetByStatus(STATUS_ACTIVE) либо вообще User::GetBannedUsers() Профит в том, что контроллеру не нужно знать каким способом модель работает с данными и каким способом эти данные получены. Можно написать Unit-тесты для сервисного слоя, для контроллера это сделать сложнее. Можно изменить хранилище данных - например вместо базы хранить в файлах, или вообще в php-массивах (иногда так и делаю со статичными данными).