bernex: Прежде всего - Doctrine и её Identity Map и Unit of Work, поддержка разных soft delete и versionable. Twig с его автоэкранированием, безопасность для CRM сверхважна. Нормальная система бандлов и мощные конфиги в том числе через анотации. Нормальный DI, не будет проблем с тестами, да и гибкость системе нужна. Мощный конпонент для работы с формами, что в случае со типизированными формами CRM сильно упрощает работу. Ну и ещё куча мелочей.
Посмотрите OroCRM https://github.com/orocrm/crm/tree/master/src/OroC... там всё довольно логично и понятно, легко поддерживать, а вот в случае с yii и laravel можно навернуть фиг пойми что, каждый разработчик по своему, а потом лови вечные регрессии.
p.s. Я очень не люблю symfony, но у вас задача именно для этого монстра.
В пятой поменяли, хорошо что завели .env файл, а вот то, что с него всё читается это ещё дебильнее. Хотелось file_get_contents(path_app("config/.env")), а там только строка с названием env, а в итоге стало ещё геморнее.
WTF? Нормально в базе хранится json, нужно использовать экранирование или подготовленные запрос и это касается не только json, а любых строк. В постгресе и вовсе json стал родным и появилась масса инструментов для работы с ним.
tushev популярность сложилась исторически был момент, когда mysql сильно выигрывал в простоте установки и хорошими дефолтными настройками. Администрирование предопределило популярность, а функциональность не столь важна для большинства проектов.
Когда видишь, как благодаря твой полугодовой работе сокращают отдел в 40 человек, то меньше всего думаешь о том, что тебе переплачивают. Деньги на зарплаты из воздуха и гос бюджета не берутся, программисты зарабатывают их своими продуктами, не нужно философствовать о пузырях.
по первой части, у себя я пофиксил баг с $_SERVER['HTTP_HOST'] перегенерил автолод и добавил слеш в название \Validator::resolver и всё заработало без проблем.
Во первых аккуратнее с переменными $_SERVER['HTTP_HOST'], они работают только для сервера, в режиме командной строки вас валятся ошибки.
С валидатором у вас всё хорошо, он подключается проблема в неймспейсе, нужно писать \Validator::resolver
C workbench у вас проблемы, потому что вы его генерировали с незаполненым конфигом, произошла ошибка валидации json и он нормально не сгенерировался. Удалите папку и пересоздайте всё заново. Затем скопируйте из бекапа нужные классы.
@SilenceOfWinter: в смысле паттерны, я предложил пару разных паттернов использования ORM, но серебрянной пули нет. Для простого проекта использование квери билдера в контроллере гораздо читабельнее и понятнее нежели репозиторий, который разносит логику по разным местам. Если проект коробочный и ядро нужно расширять в последствии бех изменения кода, то репозиторий с инъекциями рулит.
Если проект чуть посложнее, и в последствии условия выборки могут меняться, то логично не использовать билдер в контроллере, а перенести в одно место вроде scope в модели или в репозиторий.
А где-то нужно и доработать ORM, например добавить поддержку identity map и unit of works, особенно для демонов и консольных скриптов.
Нужно пользоваться головой и паттерн сам вырисуется.
Так же как вы делали, только через модель Post, если проект большой, то лучше квери билдером ползоваться только внутри модели и дергать методы через scopes laravel.com/docs/4.2/eloquent#query-scopes
@WebSpider Для второго вопроса есть Route::controller('users', 'UserController');
По первому, как сказали выше есть фильтры, это ненормально, что вы хотите один урл обрабатывать разными контроллерами. Как потом это поддерживать. Можно, конечно, использовать подход а-ля hmvc, но это тоже костыль.
Посмотрите OroCRM https://github.com/orocrm/crm/tree/master/src/OroC... там всё довольно логично и понятно, легко поддерживать, а вот в случае с yii и laravel можно навернуть фиг пойми что, каждый разработчик по своему, а потом лови вечные регрессии.
p.s. Я очень не люблю symfony, но у вас задача именно для этого монстра.