FanatPHP

https://stackoverflow.com/a/14767651/285587

Именно поэтому подход Симфони 4 рулит. Выбираешь только те компоненты, которые нужны.

Почему нехорошо? Что конкретно "нехорошего" в создании хелпера, реализующего определенный сервис и предоставляющего этот сервис различным частям приложения?

Делать жирный хелпер и захламлять его не связанными друг с другом функциями - это действительно нехорошо. Но никто же и не принуждает иметь единственный хелпер на все приложение.

куда вы предпочитаете выносить "тяжелую" логику в приложении? Чтобы не делать жирных контроллеров

В хелперы. Они именно для этого и предназначены

> не захламлять модели?

Модель - самое неудачное слово, которое существует в мире веб-разработки.
Хелпер является полноправной частью модели. А то что ты называешь моделью - слой работы с БД - это либо DBAL, либо ORM, дата маппер.
Чтобы не захламлять маппер, тебе нужен репозиторий. Тот же хелпер, но работающий с БД, коллекция специфичных SQL запросов.

Слухи о том, что CI безнадёжно устарел, безнадёжно устарели.
Буквально на днях вышла версия 3.0

А зачем проверять и какие ты собрался выполнять действия, если создать не удалось?
И пробовал ли ты выполнить такие действия при update?

Есть два варианта научиться чем-нибудь:
- либо прочитать книжку
- либо освоить на примере

ТЫ НЕ СПОСОБЕН НА ОБА

Прои взгляде на несчастную модель на глаза наворачиваются кровавые слезы.
Более-менее современная технологичная установка попросту изуродована ударами варварской дубины. НУ ХОТЯ БЫ ПОСМОТРЕТЬ, КАК СДЕЛАНО В СОСЕДНЕМ МЕТОДЕ и не лепить SQL руками можно было? Дай классической похапе-обезьяне Ларавель - она и из него сделает привычную mysql_query.

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

Я был неправ, приношу свои извинения.
Это принципиальное ограничение для eager loading, и текущее поведение - это единственное, что он может дать. То есть, смысла использовать hasMany тут нету.

То есть, комментарии надо получать отдельными запросами, по числу постов, что возвращает нас к предыдущей задаче про денормализацию. Хотя я бы не торопился её делать, поскольку 20 запросов по индексу базу не нагрузят.

Основная проблема в том, что у популярных РНР фреймворков нет модели вообще.
А моделью называется тот самый ORM.

Соответственно, от использования ОРМ в контроллере отказаться в принципе невозможно. А сама идеология фреймворка склоняет к тому, что моделью выступает контроллер - в котором и пишется вся бизнес-логика.

В случае с Ларавелью мы получаем

• Модели лежит в папке Controllers, при этом используя
  • ORM из папки Models для манипуляции с данными
• Визуальное отображение лежит в папке Views
• Секретарша лежит в routes.php.

Отсюда становится видно, что проблема с квери-билдерами - мелкая и надуманная. И для её решения достаточно применить здравый смысл - если вызов однострочный и читаемый, то дергаем прямо в контроллере. Если посложнее - делаем отдельный метод в "модели".