Я почему тему-то затронул про "наилучшую реализацию" - потому что это ключ к ответу на все вопросы и здесь почвы поговорить гораздо больше, чем высасывать из пальца M...V...C....
В моем понимании идеальная минимальная сборка CMS должна:
1. "Состоять из приложений" (сайт - конечная морда, отдаваемая клиенту, админка - интерфейс для административной группы, crm какой-нить и т.д.)
/applications/site/ (например)
/applications/adm/ (например)
/applications/crm/ (например)
2. Иметь понятие "модуль" (как ни крути, у модуля есть своя статика - макеты, css, js, есть контроллеры и акты), имхо, сложно назвать news, например, просто контроллером с набором моделей, т.к. нужно как-то в древовидной структуре систематизировать все файлы, а отделять статику модуля от скриптов, конечно, - можно, но пропадает систематизация.
3. Модуль должен состоять из:
3.1. Контроллеры
3.2. Модели
3.3. Статика
3.1.1. Все это лежит в одной папке, например, news
news
news/static
news/controllers
news/models
news/config.php
При этом:
/applications/site/news/ (например)
4. Реализация ООП должна быть минимальной (уже вижу, как летят в мою сторону камни)
4.1. Я уже писал где-то, что, на мой взгляд, ООП создает немало "зависимостей" по всему коду.. один наследует одно, последующий другое и т.д.
Появляется необходимость бдительной отладки и документации деталей, учета массы иных вариантов.
Ведь по сути-то, нам нужно
просто обработать запрос и послать его на верный контроллер, а некоторые эту процедуру превращают в полет фантазии и рождаются CMS с более 100 инклудов за один проход. Опять же, это все субъективное мнение относительно ООП. Мне лично подходит реализация классами с точки зрения группировки однородных функций, но пока не встречал надобности в наследовании "на каждом шагу".
4.3. Все методы должны носить минималистические названия, понятные не только автору (не имеет значения, есть фак и нет)
5. View не должен превращаться в отдельный язык программирования. Его функция разобрать сущности в макете, например, {foo} - это переменная, {foo(bar)} - это функци, {*say_hello*} - это языковая сущность $lang_var['say_hello']
5.1. Вьюха пассивная или активная, вот это вопрос. В такой реализации минимальной, то и разницы-то не будет по скорости (не мерял, это допущение)
ну и еще масса мелких моментов, например:
- Стоит ли делать как в ZF инклуд файлов с поиском по заведомо заданным базовым путям, если сами разработчики указывают на оптимизацию очередности этих путей, чтобы не возникало "задержек"?
- Кеширование на файлах, - часть данных кешируется, преобразовывая некоторые сущности из макета, а некоторые оставляет для обработки и вызова функционала, иная часть кешируется memcached, например, некоторые тяжелые mysql запросы.
-- имхо, кеширование, одно из реально узких мест всегда
- RBAC разделение прав доступа к контроллеру, только оно будет требовать описание отдельного массива, например: $access[1]['addUser'] = true (разрешить группе юзеров с ID == 1 доступ к контроллеру). Возможно, у вас иные мысли на этот счет?
....
Я не претендую изобрести что-то новое и рвать стереотипы, но, полагаю, что для реализации быстрой, надежной и безопасной системы достаточно уложиться в 100-200 кб. (включая репозиторий: работа с формами и т.п.).
P.S. Вообще, я бы с радостью поучаствовал в каком-то совместном открытом проекте по реализации нечто такого минималистического, не нагруженного переизбытком умственного потенциала, где понятие "это нужно" обосновывается, а не впихивается клочками кода "про запас", а допустим лишь рост библиотеки хелперов и прочего функционала
P.S. Надеюсь, я разрядил немного тему споров "есть или нет MVC"
