@Insayt вы просто привели далеко не лучший пример реализации на Yii. Хотя согласен, в Laravel с этим проще. Но суть все та же, есть валидация запросов (по методу например), есть роутинг, есть возможность отправлять сериализованные данные, при желании можно подключить все что нужно. Хотя в контексте Yii намного сложнее и выглядеть будет не так опрятно.
Я лично для REST апишек использую Silex (+аннотации. doctrine, jms-serializer и кучи других плюшек для сборки и разработки), хотя проще использовать Symfony где настройка шаблона проекта займет куда меньше времени. Шаблон же потом реюзаю.
Что до "установил и в бой", смотря какой проект. Для большинства да, но нужно все же потратить время на настройку всех зависимостей, подготовить каркас, внедрить тесты (PhpSpec2, Behat и т.д.), всякие mess и copy-paste детекторы ну и т.д. Хотя на простых проектах это все не нужно.
выделите основные компоненты фреймворка (раутинг, работа с БД, Dependency Injection) и вперед к реализации. По каждому компоненту есть тонны статей в сети а так же тут частенько про тот же роутинг вопросы проскакивали.
@StrangeAttractor Phalcon идет в виде экстеншена для PHP. То есть вы должны иметь возможность его установить, а не многие shared хостинги под это описания подойдут. Я лично даже и не знаю таких. Только VDS, благо они сейчас не сильно дороже шаредов.
@young8junkie RoR не панацея. Пару раз приходили проекты на RoR написанные через одно место. То есть тут нужно объективно оценивать разработчиков, проводить собесы и т.д.
Конторы которые разрабатывают на симфони, через TDD/BDD/DDD имееются, причем даже не мало, но все что я знаю работают преимущественно со штатами/англией. Да и рейты у таких контор... Словом дешевле найти разработчиков-фрилансеров с большим опытом работы с симфони, и выставить жесткие требования.
@fornit1917, я не пробовал Yii2 в плотную, но вот то что не решается без кастылей в Yii1: валидация форм (а точнее убогая реализация групп валидации), отсутствие мэппинга полей из базы в модель. Отвратительная работа со связанными сущностями (попробуйте поработать с пару месяцев на Doctrine, потом будете на Yii-шный AR смотреть с тоской), убогая система маршрутизации, некоторые вещи решаются только жирными классами CRoute, реализация CHttpRequest завязана на суперглобальных переменных (собственно как и в Yii2), от чего добавление таких полезных штук как мидлвары крайне неприятное удовольствие. Так же крайне неприятно вводить штуки аля ParamConverter в Symfony (довольно удобная штука иногда).
Я не спорю что можно, но у вас нету достаточного опыта работы с другими фреймворками.
p.s. Это очень грустный код... Согласитесь, необходимость в подобных велосипедах не от хорошей жизни.
@fornit1917, они не нужны для проектов однодневок, типа стандартные бложики/сайты визитки и т.д. Но если проекту требуется развития, нужны тесты, нужна минимизация накладных расходов на разработку (минимизация времени затрачиваемого на рефакторинг, поиск регрессий и т.д.) Все эти штуки, типа принцип единой отвественности, горы интерфейсов, слабосвязанные-системы и т.д. как раз таки и призваны сделать код динамичным.
Хороший пример когда эти "ненужные" штуки спасают проект - клиент с безлимитным бюджетом (то есть вы работаете пока он платит деньги, нету фиксированных сроков и т.д.), который на момент начала проекта не знает и на 10% того, что он хочет в итоге видеть. Тут годятся только слабосвязанные системы, когда один компонент не знает как работает другой. В Yii же у вас один компонент (ActiveRecord) отвечает и за хранение данных, и за хранение предметной области и за валидацию... В итоге вырастает иерархия классов, ибо нужно всегда иметь возможность перегрузить глобально метод delete допустим, для каких-то своих целей (типа той же внезапно появившейся в спеке версионизации). Я видел подобное, и не в восторге как-то.
Yii - хорошо на фикстпрайс с жесткими договорами, ТЗ и прочим. Но если у вас раз в месяц меняются требования, или же нужно часто расширять функционал (что обычное дело для больших проектов) можно упереться в растущие затраты на поддержку и дальнейшую разработку.
Для миграций? Мы используем doctrine-migrate, но у нас и проекты используют Doctrine ORM. По сути у вас будет история изменения структуры базы и возможность откатываться до любой точки. А если делать изменения понемногу, проблем с миграциями быть не должно. Учитывая ваше желание деплоиться несколько раз на дню - я думаю у вас будет именно такой подход.
Я лично для REST апишек использую Silex (+аннотации. doctrine, jms-serializer и кучи других плюшек для сборки и разработки), хотя проще использовать Symfony где настройка шаблона проекта займет куда меньше времени. Шаблон же потом реюзаю.
Что до "установил и в бой", смотря какой проект. Для большинства да, но нужно все же потратить время на настройку всех зависимостей, подготовить каркас, внедрить тесты (PhpSpec2, Behat и т.д.), всякие mess и copy-paste детекторы ну и т.д. Хотя на простых проектах это все не нужно.