С пятницей коллеги!
Заинтересовал меня намедни такой вопрос: какой PHP фреймворк вы выберете для создания среднего или крупного проекта (корпоративный портал, магазин и т.п.) в 2016 году?
Уточню, что это не холивар, какой фреймворк лучше, речь идет именно о вашем личном выборе, причины которого, могут быть любыми.
И да, Bitrix это не совсем фреймворк, но тем не менее.
UPD: Подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на этом. Хочется узнать фактический мейнстрим на 2016 год, то есть, что будет на самом деле, а ни этот хороший, а тот плохой.

Постановка задачи. Имеется действующий отлаженный проект на PHP, содержащий десяток моделей, в каждой из которых по 5 методов выборок данных. Проект растет, всё хорошо, но в определенный момент, под тяжестью нагрузки, назревает необходимость добавить каким-то образом кэширование обращений к моделям.

Возможные решения.

Первый способ «в лоб»: в каждый метод модели добавляем кэширование по стандартной схеме: проверить кэш, если есть актуальные данные, возвращаем их, если нет — выполняем метод, как было до этого и плюс в конце еще пишем, полученные из базы, данные в кэш. Сказать, что это ужасный способ значит, ничего не сказать, поэтому просто скажу, почему это плохо:

1. Нарушается один из принципов SOLID, «код должен быть открыт для расширения, но закрыт для изменений», т.е. мы берем и ломаем уже отлаженный выпущенный в продакшн код для того, чтобы добавить новую функциональность, а это всегда вызывает шквал ошибок и как следствие недовольство пользователей и заказчика.
2. В одном и том же коде смешивается логика получения данных и кэширование, что приводит к распуханию классов и беспощадному повторению кода.
3. Сделав так, мы лишаемся возможности получить живые данные в обход кэша (следующим шагом будет добавление флага $nocache).
4. Очень высокая трудоёмкость впиливания кэширования таким способом и ещё большая трудоёмкость выпиливания его потом.

Второй способ, «расширяем классы моделей»: добавляем в модели методы-дублеры, которые оборачивают вызовы существующих методов в кэширование, например findById_Cached().
Вроде бы лучше, существующие методы не трогаем, вместо этого добавляем новые. Но остальные минусы на месте:

1. Смешивание логики.
2. Размеры классов растут ещё больше, чем в предыдущем способе.
3. Очень высокая трудоемкость (добавить 50 новых методов, в нашем примере) + заменить везде в приложении вызовы старых методов, на новые, а если в будущем придется кэширование выпиливать, то еще и повторить все действия назад.

Третий способ «кэширующий прокси», очень простое и быстрое решение, поражающее своим изяществом и скоростью внедрения. Как его сделать – смотрим код.

Добрый день коллеги, сегодня я расскажу сказку о своём опыте организации контроллеров в проекте на ZF 1 (так исторически сложилось).
В хороших книжках по ООП часто пишут, что наследованием нельзя увлекаться, нужно предпочитать делегирование или делать так, чтобы они работали совместно. К сожалению, не всегда можно быстро догадаться, как применить сухую теорию на практике (а когда наконец-то доходит, удивляешься «что тут сложного?»), поэтому надеюсь мой опыт кому-нибудь пригодится.

И так сначала о проблемной области:
31 Controller Action, большинство из них имеет методы indexAction(), addAction(), editAction(), searchAction().
проблема №1: большинство, но не все. В остальных наличие этих методов варьируется,
проблема №2: методы editAction() и addAction() массивные сами по себе, и почти одинаковые для всех контроллеров, отличаются инициализация формы, и сохранение модели.

Как я это решил, покажу сразу в коде.

Доброго времени суток коллеги.
Как вы относитесь к использованию ORM в PHP проектах?
Я очень люблю ORM и QueryBuilder-ы, но вот конкретная реализацию ORM Doctrine 1, очень разочаровала: неоднозначные фичи, вроде ленивой загрузки поля, очень большой оверхед по памяти и времени работы скрипта, не гибкость, нельзя сохранить один конкретный объект из дерева и еще некоторые вещи. Всё это наводит на мысль отказа от Doctrine, поэтому хотелось бы узнать о практическом опыте сообщества.
UPD если проголосовали за последний пункт, напишите пожалуйста в комментариях, какой фреймворк, какие подводные камни были.

Коллеги расскажите, пожалуйста. как вы делаете деплой на production сервер(сервера) веб-проектов.
Если у вас используется 3 или 4 вариант, то как вы переключаете document_root — создаете симлинк на новый релиз или переписываете (скриптом) конфиг nginx?
Если переключать симлинк не бывает проблем с APC или XCache?
Если не хватает какого то варианта пишите в комментарии.

UPD: Спасибо всем за комментарии, пятничный пост получился очень продуктивным и полезным думаю для многих.
UPD2: Небольшой обзор комментариев:
подробные разборы деплоя habrahabr.ru/post/211733/#comment_7286111 habrahabr.ru/post/211733/#comment_7287769
утилиты для создания deb пакетов habrahabr.ru/post/211733/#comment_7286187
наиболее популярное готовое ПО capistrano, fabric, teamcity

Сразу скажу, что опытным программистом откровения не будет, грабли тривиальные.
Все знают, что в моделях недопустимо использовать суперглобальные массивы $_POST, $_SESSION, $_SERVER и т.д., поскольку это делает невозможным усложняет тестирование кода и его повторное использование. Но если суперглобальные массивы, всё-таки, при желании можно «хакнуть» (разумеется это уже за гранью добра и зла), то другую менее очевидную зависимость от глобального окружения — уже никак.
Я говорю о времени — такую зависимость вы добавляете в свой код, когда используете в php-модели time() ( date() без аргумента timestamp) или в MySql-запросе now() (sysdate в Oracle). «Хакнуть» время сервера, чтобы узнать как поведет себя ваш запрос завтра или вчера — задача нетривиальная.
Как это происходит.

Сразу оговорюсь, это не обучающий пост и не провозглашение новой парадигмы )), скорее решение, к которому я пришел, и хочется его обсудить в широкой и честной дискуссии.
Теперь к сути, представьте, что есть некая ORM, написанная на PHP, в которой описана модель Posts, имеющая связи многие-ко-многим через промежуточные таблицы с другими моделями: Comments, Tags, Categories. Вопрос в том, каким способом лучше поднимать связанные данные, всё сразу или с отложенной загрузкой?

Начиная с версии 5.3, PHP позволяет создавать замыкания. К сожалению, пример их использования в официальной документации http://www.php.net/manual/en/functions.anonymous.php#example-163 (example 3) обладает редкой изощрённостью и надуманностью. Надеюсь, пример под катом поможет увидеть в замыканиях другое применение, кроме как с функциями типа array_map().