neyronius

Однозначно отказать — cakephp и codeigniter
Скорее всего отказать — zend
Остальное — дело вкуса. Yii неплох, но он на любителя. Мне, например, совершенно не пошел.
Kohana очень неплохой фреймворк, но у него очень плохо с документацией, плюс тот рефакторинг, который затеяли в последнее время не внушает надежд на устойчивое развитие. Не хочется новичку его советовать. Хотя, повторюсь, фреймворк мне очень и очень нравится.
Symphony2 — это то, что сейчас находится на острие развития php-фреймворков. Из данного списка я выбрал бы его.

Но хочу предложить вам альтернативный вариант — Laravel, laravel.com
Он замечательно документирован, написан с нуля год назад, с учетом косяков старых фреймворков и полезных фишек из RoR, у него бодрое, грамотное, хоть пока и не очень многочисленное комьюнити, по нему есть туториалы и даже уже написана книга — daylerees.com/category/laravel-tutorials/. Правда, в рунете он практически неизвестен.

Вы правильно склоняетесь, причем учите три, делайте на них одно и тоже и в итоге будете знать разницу, а знать разницу более ценно нежели уметь что-то делать.

CakePHP уродливый внутри и давно устарел. Сейчас все юзают Yii. Kohana — не самостоятельный фреймворк, а улучшенная версия CI. Symphony — вроде тяжелый и оверинженеренный монстр, который включает в себя неуклюже скопированный из Java ORM.

Есть также мнение, что лучше всего было бы вообще перейти с PHP и недофреймворков на что-то серьезное, например Java (Гугл использует Java и С++ для своих сервисов, например) или хотя бы python, если яву не осилить.

>Но когда появился большой трафик (примерно 2-3 000 одновременных соединений),
>появилась проблема ошибки 502
php-fpm это не серебряная пуля которая решить данную проблему. Очевидно же, что суть проблем в том, что бэкэнд не успевает переварить такой всплеск нагрузки. Как я понял, при это есть свободные ресурсы, значит нужно крутить настройки сервера.

Увеличте backlog бэкэнда, запросы которые он не сможет принять буду ставиться в очередь. Но увлекаться этим не стоит, пользователь не будет у вас ждать, пока его запрос из backlog будет бэкэндом взят и обработан. Значит смотрите в сторону ускорения приложения. Сколько времени генериться страница? Если ли страницы которые одинаковы для всех? Выносите их в memcached и забирайте самим nginx-ом, не дергайте лишних раз бэкэнд. Включены ли акселераторы в духе XCache? Все ли скрипты при этом в кэше? Как обстоят дела с соединения к базе, сколько по времени они занимаются? Используется ли кэширование на этом уровне? К примеру, у меня в случае забора ответа от СУБД страница в среднем на одном проекте генерится ~15-20 мс, если данные забираются из кэша в роли которого работает Redis, то величина падает до ~2-10 мс, т.е. до 10 раз. И бэкэнд готов обрабатывать следующий запрос.

В общем обращаю внимание, что установка php-fpm чудесным образом ситуацию может не изменить, хотя возможно сгладит её.

Делайте на пхп, Вы его уже похоже знаете, не стоит выделываться на проектах новыми языками, новые языки самое оно учить, когда в команде есть хотябы один хорошо его знающий. Иначе есть шанс зайти в клоаку по незнанию, на мануалах далеко не уедешь. node.js хорошая вешь, но там принцип совершенно противоположный от того что люди привыкли в пхп (и подобных линейных языках) видеть, есть шанс такого наделать что и дар не будешь.

Мне кажется делиться особо нечем. Код понятен ввиду своего малого объема.
Попробуйте сами CMS написать, хотя бы по одному-двум коммиту в неделю делайте.
Я для сайтов визиток сделал cms на SlimFramework с нужным, в большинстве случаев, мне функционалом.

ИМХО, задача реквеста — принять входящие данные (POST/GET/COOKIE и прочие заголовки), инициировать запуск нужного метода контроллера, и вернуть реквест с результатом. Соответственно, вся логика (валидация, запросы к БД и т.д.) должна лежать в контроллере, но не запросе. Request — служебный класс, и его имеет смысл разбивать на подклассы, если возможны различные варианты обработки входящего запроса, но никак не подстраиваться под бизнес-логику.

Очень сильно зависит от уровня, очевидно, но факт.
Среди индусов очень много «писателей», это минимальная цена за отборный говнокод при достаточно большой скорости. Иногда это нужно.
Неплохая прослойка среднего уровня прогеров, которые пальцем не шевельнут что бы сделать что-то вне ТЗ. Сказано «скрипт размещения новостей» — будет Вам скрипт размещения новостей, не ждите только увидеть там опцию удаления новости или редактирования, потому что ТЗ было на размещение.
Высокого уровня индусов как таковых мало, они как правило уходят на аутсорс в штаты и цены у них соразмерные, или тупо реселлят средних прогеров, что тоже сказывается на ценах. Так что в них смысла немного.

Если четко ставить задачу и не гнаться за мин.ценником, то можно получить решение задачи раза в 2 дешевле русских кодеров, при прочих равных. Однако высокого уровня индусов и простых солдат быдлокодеров лучше избегать.

На мой взгляд — не имеет смысла, реквест должен описывать только логику HTTP и не должен ничего знать о конкретике передаваемых в нём данных. Валидировать запрос должен валидатор после раутинга.

Вы знаете, вот вы меня все будете ругать и бить, но я в большинстве проектов, где использую CMS использую Битрикс.

Да — там ужасная архитектура, на многие вещи приходится плеваться и ругаться. И можно еще много всего сказать.

теперь основное:

Чтобы сделать простой сайт и его ± в стандартных рамках кастомизировать / допилить — у меня уходит очень мало времени, есть достаточно гибкая работа с шаблонами, где я свободен и волен делать все что мне вздумается (на один проект устанавливал модулем второе ядро с yii, но это слишком специфично :) )

Идем дальше — есть куча бумажек / сертификатов, которые любят заказчики (да, говорите, что грошь цена им и тд).
Еще дальше — смотрим документацию. Для разработчиков с ней беда, скажу честно и откровенно. Не хватает. Но отдать пользователям на откуп. И тебя не дергают лишний раз, по крайней мере действительно многое решается словами «почитайте в документации. В таком то разделе подробно описан ваш вопрос».
Если что-то не работает — не стесняясь отправляю в техподдержку, которая либо входит в стоимость лицензии (1 год), либо по своей партнерской.

В качестве резюме, как разработчик, у меня двоякое ощущение от Битрикс, я очень долго не хотел его даже смотреть (не один год шла внутренняя борьба), но вот уже как более 2-х лет партнер. В качестве менеджера — скажу еще более прямо — Битрикс помогает мне зарабатывать деньги большие, чем любая другая CMS за счет своего бренда и маркетинга.

Чтобы комментарий не казался холиварным — еще пробую работать с UMI, идеология очень нравится, но какое то внутреннее отчуждение… тяжело идет.

Раньше работал с WP. Joomla не переношу на дух, это скорее не объяснимо, просто ИМХО :)

в качестве фреймворков активно использую/вал CodeIgniter. Сейчас начал смотреть в сторону Yii.

Лично мне больше всего по душе Wordpress, так как, на мой взгляд, он наиболее прост в обращении, легко расширяем (плагины, которые ставятся простым кликом в админке и которых очень много), быстр и не потребляет много ресурсов. Однако он все же заточен под блоги (хотя можно использовать для чего угодно, но потребуются «переделки»). Так что еще использую Joomla. Последняя мне нравится так же, хотя с ней работать капельку сложнее, +большее потребление ресурсов и более низкая скорость работы в сравнении с WP.

Еще есть интересный движок InstantCMS. Мне понравился тем, что он действительно быстрый. Но, к сожалению, пока не очень распространен, так что дополнений для него немного.

Упс! Сорри, тут про CMS, а я про фреймворк. Еще раз извиняюсь.

Propel или Propel2
офигенная ORM с генерацией запросов.

Ах да, и Doctrine2 нифига не ActiveRecord. Для Rapid Application Development скорее не подходит. Но если у вас сложный проект, то тогда стоит подумать об использовании DataMapper.

Если в production, то точно Doctrine+Symfony

PHP-шниками не становятся, ими рождаются…

Попробуйте выделить отдельный класс, который будет отвечать за данные, которые нужно послать в БД или вытащить из нее, а при сохранении в БД в контроллере запрашивайте этот класс из формы и отдавайте его на растерзание классу БД (или терзайте прямо там).

Форма как элемент UI не должна знать про БД, но должна отдавать данные в каком-то виде. Контроллер как прослойка между UI и DB должен превращать данные из UI в данные, пригодные для DB.

Походу ответ похож на предыдущий (^_^)

Возможно, вам стоит создать отдельные классы-Entity, которыми и манипулировать на всех слоях приложения.
M, V и C — это «подслои» UI. А кроме UI часто выделяют отдельные слои бизнес-логики (BLL) и доступа к данным (DAL). Таким образом, в своем MVC вы можете манипулировать данными, а затем передавать их в виде Entity-объектов в классы бизнес-логики, которая, в свою очередь, будет вызывать методы доступа данных для CRUD-операций.

Это всего лишь один из вариантов архитектуры. Все зависит от конкретного приложения, но подробности у вас бы вряд ли уместились в вопрос, так что… думайте, выбирайте :) Или же задавайте более конкретные вопросы.

Судя по всему, вам необходимо хранилище типа «ключ-значение». Если не хотите заморачиваться с NoSQL базами, используйте возможности опкод-кэшера APC (apc_store / apc_fetch).
Про синглтон и Zend_Registry выше уже написали. Удачи!

Что-то никто про redis не вспомнил :)
habrahabr.ru/blogs/webdev/76388/