Несколько модулей в CMS, что из них контролер и что тогда остальное

Несколько модулей в CMS, что из них контролер и что тогда остальное

Здравствуйте. Все пишут CMS. Уже наверное пошел третий год, как я не могу закончить свою CMS. Дилемма о паттерне MVC мучает. Каждый изобретает свой велосипед. У меня из модели (БД) выбираются имена файлов, где хранятся классы (модули, блаблабла). Каждый исполняет свою роль (юзеры, языки, шаблонизатор и т.д.). По сути эти все классы имеют отношение к контроллеру или есть ним (из определения "контроллер"). Все они исполняют запросы к модели и наполняют представление. Одно не сходиться - они, модули или классы, не реагируют на данные отправленные пользователем как сказано в определении, а используют в основном результаты исполнения предыдущих классов. Например,
PHP:
blocks :: Singleton() -> Set(menus :: Factory('topmenu') -> Render(true), menus :: Factory('topmenu') -> GetPosition());
Т.е. видно что объект класса blocks использует результат работы объекта класса menus и отношения к запросу пользователя там нет. С другой стороны вышеприведенный код вызывался из самого первого объекта класса
PHP:
loader :: Singleton();
и только он реагирует на URL (разбирает URL роутер, вызывает лоадер с параметрами из URL) пользователя. Что же я хочу услышать: объясните пожалуйста где здесь тогда контроллер? Контроллер это все классы или только лоадер (тогда что остальное такое)?
Спасибо за ответы, а то я запутался и не знаю верна ли моя схема.
 
имена - это образно. Конкретнее тип varchar(255) "appcall" со значениями типа: languages, users, blocks. А потом
PHP:
$result = database :: Singleton() -> FetchRows();
foreach($result as $module_name) {
include('/path/to/modules/' . $module_name['appcall'] . '/' . $module_name['appcall'] . '.autoload.php');
}
-~{}~ 01.03.10 14:58:

Конечно инклуд в цикле и это не кошерно, но я на хайлоад и не рассчитываю.
 

HraKK

Мудак
Команда форума
А по теме - блоки это не контроллер, это обьект который делает работу с блоками, а контроллер - он на основании Request_Http решает что сделать - вывести такой-то и такой блок допустим.
 
Так и есть. Но что есть "блок" в модели паттерне MVC?

-~{}~ 01.03.10 15:07:

Написал не правильно.
 

HraKK

Мудак
Команда форума
ничего.

-~{}~ 01.03.10 16:31:

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

-~{}~ 01.03.10 23:46:

Мой пост, конечно, выглядит, как будто я стремлюсь только к тому, чтобы сказать "...а у меня MVC". Хочу понять что я делаю и делаю ли я это правильно, так как книжка википедия пишет.
 

Бочонок

http://frontender.info
Ммм ... можно вопрос?
Насколько я понимаю в MVC функция контроллера сводится к тому что бы получить запрос/данные от пользователя опосредовано представлению и передать их модели (перенаправить нужному модулю). Где уже и происходит авторизация, аутентификация и любые другие действия.
Разве не так?
 
В моем понимании модель - база данных (не запросы, не слои, не классы для работы с базой, только сама БД), представление (не шаблонизатор, не кэш, только шаблон в виде html, xml и т.д.), а вот контроллер, в моем понимании - код (не html, не xml, только код на PHP, Perl, C и т.д.) который реагирует на какие либо действия пользователя или на результаты действия. Тогда исходя из того, как я понимаю, контроллером есть все, что есть код (и блоки, и модули, и классы и т.д.)
Мой вопрос остается в силе.
 

Духовность™

Продвинутый новичок
В моем понимании модель - база данных (не запросы, не слои, не классы для работы с базой, только сама БД)
Модель скрывает работу с базой и логикой. Если у тебя модель == база, то куда девается вся логика программы? В контроллер?
 

Бочонок

http://frontender.info
Curly-fingers паттерны используются для ускорения процесса разработки и удобства. Разработки и поддержки. Нет никакой пользы в том, что бы возводить их в абсолют.

P.S. комментарии у вас меняются быстро.

P.P.S. А само MVC разобрано по косточкам в тысячах статей. И суть его в разделении представления, данных и логики работы приложения. И реализовать это разделение можно по разному. Главное что бы тебе и тем, кто работает над проектом с тобой было удобно.
 

Бочонок

http://frontender.info
Да. Половина - говно.
Но вторая половина содержит рациональное зерно.
А на практике нужна только одна хорошая статья. И думаю среди этой половины она все же найдется.
В крайнем случае всегда можно начать с начала. С GoF.
 
Сверху