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

Хм тогда проще писать в процедурном стиле )) Как по мне - то лучше в целом пусть отожрется на 2 метра больше за то в угоду удобства и гибкости


Так реквест же это не редиректор какой нить. Реквест, запрос. Завтра тебе понадобится сделать редирект по имени роута его тоже в реквест оформишь или пойдешь переписывать все двигло где ты вызывал Request::redirect() ? Или нет, дай угадаю, редирект оставишь в реквесте а для роут-редиректа придумаешь что то ещё))


А у тебя есть такой роут? Думаю нет... там же пользователь и получит заветный Not found

Порой экономия на спичках дорого обходится поверь

В точку! Записал в TODO с пометкой "подумать кому рассовать ф-ционал".
(Добавление)
Ой не сравнивай, процедурка в пыхе это адъ. Если в сях хотябы глобальные переменные можно без костылей, то в пыхе будешь везде писать global внутри ф-ций ))
У нас там автороут, без описания маршрутов. Положил контроллер в папочку - получи точку доступа. Именно поэтому нет смысла вообще этот автороут запускать если запрос невалид.

Помечу оффтопом. Многие в курсе моего отношения к "спичкам".

Шардирование конечно на стороне приложения. А файловер - неверняка решения есть, я к сожалению только в постгресе ориентируюсь по кластерным решениям. Ну просто никакого профита от переноса это в приложение не вижу.

Нарыл вот такое
Как оно? Будет съедобно?
(Добавление)
Еще один путь
(Добавление)
Засим, я пока пропущу момент с пинанием конекшнов, на сейчас закостылю сингловый.
А когда устаканим что и как именно будет использоваться - при необходимости поправлю.
Сейчас же двинусь дальше, тут вон, две страницы критики, есть чем заняться.

Почему бы не внедрить Service Locator?

Поддерживаю тех, кто говорит про спички. В итоге спички могут встать боком и стоить гораздо дороже. Всё же это PHP. Если ты так гонишься за оптимизацией, давай тогда делать на CGI или Java
(Добавление)
Как по мне, так редиректить должен роутер или респонс. Но точно не реквест.
Реквест не должен выполнять каких то действий, он пассивен - получил данные, отдал данные.

Редирект по сути всего лишь заголовок, так что в респонсе ему есть место быть.
Если понадобится редирект на роут, то у роутера запрашиваем URL по роуту и передаём его в метод редиректа респонса.

а сколько то физических серверов есть чтобы думать о кластере. возможно их два или вообще один. тогда какой может быть кластер.

1. автолоадер лучше подключать извне а не в индексе
2. все о том же автолоадере. я предпочитаю абсолютные пути и поетому добавил бы ROOT директорию пред подключением. но это ИМХО
3. App::run($useMemory, $startTime, $isCLI); - логичней если дебаг, то внутри метода запоминать и визивать функции memory_get_usage, microtime. это ж глобальные переменные . причем функции всегда визиваються. а по сути перед этим практически никакой логики кроме инициализации констант и автолоадера нету.
4. в App::run куча статикы инициализаций нагло вшитий. ИМХО лучше сервис локатор или фабрику дергать
5. ДБ - я уже говорил что тут лугче использовать Lazy Load. зачем дергать базу, если она может и не нужна будет.
6. реквест я все же бі сделал не статичным. там можно было даже использовать два наследника один для веба ($_GET, $_POST, $_SERVER) другой для CLI (argc, argv)
7. на счет View. мне больше нравиться return в action-е. например return $this->rendrer('view_path', array($params));

это я так бегло глянул в код. все написаное ИМХО

Еще 1 важнейшиейший вопрос. Почему то никто даже не упомянул его. Может я что то пропустил?
Как планируется управлять зависимостями? Только не говорите что через pear
(Добавление)
И как обстоят дела с ресурсами типо цсс картинок итд? Будут они храниться в куче или предусмотрен (планируется) компонент управления ресурсами и их зависимостями?

Это же закладка на будущее.
Я оформил в индексе, т.к. сразу же вызываю App уже без "позорных" инклюд.
А оно там есть - константа APPLICATION. Единственное - все ядерные компоненты лежат в глобальном неймспейсе.
Так эту логику счетчик тоже считает, потому и объявлено в самом-самом начале.
init() === статический __construct(). Подробности в самом низу.
Суть уловил, разберемся с местер-слейв, заодно и с ленью базы. Я кстати Мелкому задавал вопрос делать ли ленивые коннекты. Он пока не ответил.
"Ну вот опять" - подумал горшок с петуньей.
А мне нравится возможность набросать данных и затем одной командой переопределить (указать) формат фозвращаемых данных - html, xml, json, txt.
Какими?
Сейчас просто лежат в отдельном месте, разложены аккуратными кучками.
Если придет Дельфин - то точно будет LESS/SASS. Он это дело любит.

Про статику:

Объясните в чем профит создавать экземпляры когда заранее известно, что это синглтоны? И в чем профит для
AnotherWrapper::getSomeClassInstance('Blah')->method();
или
$AnotherWrapper->Blah->method();
или
$AnotherWrapper->getBlah()->method();
или
function ($Blah) { $this->Blah = $Blah;
относительно к

\Blah::method();

Вам же самим придется думать как передать желаемую сущность куда-то, через аргумент или дергать еще одну вспомогательну сущность, чтобы получить ссылку на нужную.
Вот оно - классы ради классов, ООП ради ООП.
Посмотрите как начинаются статьи в интернете - почти все, со слов "Проблемы создания, хранения и получения экземпляра." и даются паттерны для решения.
Ага, написать и оттестировать еще 1-3 вспомогательных класса просто для того, чтобы обеспечить доступность сущностей в других местах.
И это только потому, что эти сущности изначально где-то объявлены через new Entity();
К чему создавать лишние экземпляры? Ты сам же будешь потом еще думать кого позвать для той или иной цели.
Это я вам как горшок с петуньей говорю, кашалоты вы мои ))
(Добавление)
Шило на мыло?
Да, я уже ответил паноптику, что вынесу редирект и хедеры в респонз.

Пропустил, значит. Да, конечно, делать.

DeepVarvar не злись я сказал что это мое мнение. лично я считаю все же создание обьекта лучеш статики, потому что потом можно легко его подменить, а такие случаи я встречал за свою практику. Вот и моенно поетому взял для себя за правило минимум статики. если мне нужен синглтон, то например сервис-локатор умеет делать синглтон (да знаю там все равно будет инстанс внутри). Но здесь идеть речь не ООП ради ООП, а ООП ради удобства не более. С таким подходом зачем тогда на будущее делать класеризацию, если нельзя на будущее нельзя делать подмену обьектов. вот к чему я веду.

П.С. да знаю все набросились на тебя одного ибо каждый видит этот сранный ООП по своему и каждий пишет по своему как ни крути (особенно в ПХП). но ты же хотел критики, вот тебе и критика )))

Да не злюсь я, просто юмор такой с кашалотом.
А если надо будет подменить локатор? ))
Шашечки или ехать?
В частности - напомню, что моя защита статики касается только глобально используемых сингтонов-инстансов, остальные то у нас лениво лежат в App ну и коннекты в отдельном месте.
(Добавление)
А что насчет вариантов на стороне мускуля?

И еще - ты писал что не любишь актив-рекорд модели, я скажу что я их вообще не люблю.
Но это не дело будет - обделить остальных хоть какими-то моделями.
Так вот, какими ты видишь модели?

я пропоную сделать небольшой хедпер аля DBL для быстрого INSERT, UPDATE, DELETE
например