@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. По сути у вас будет история изменения структуры базы и возможность откатываться до любой точки. А если делать изменения понемногу, проблем с миграциями быть не должно. Учитывая ваше желание деплоиться несколько раз на дню - я думаю у вас будет именно такой подход.
@nepster09 абстрактный класс - можно. Вы можете просто какой-то метод, от которого зависит реализация сделать абстрактным.
Суть в другом. Автор модуля должен предоставить готовые модели, которые можно расширить, назначить таблицу и т.д. Словом как это будет сториться в базе должен решать разработчик приложения а не модуля.
@IonDen ну да... держать у себя гору миксинов, следить за их актуальностью и т.д. это намного удобнее чем просто использовать плюшки css3 и не париться по поводу префиксов, а просто указать в конфиге сборки какие браузеры мы суппортим.