Что плохого и критично неприемлемого в Codeigniter?

Question

[coderisimo]

Я понимаю что вопрос странный , но тем не менее.
Так ли уж мертв Codeigniter?
Среди крутых (или желающих ими казаться) программистов хороший тон написать , что это мертвый фреймворк, что он зло,что он ужасен итд. По факту есть куча упоминаний о нем, как об одном из 10ти(7ми , 3х) из ныне здравствующих и использующихся. Это реальность.
Я честно пытался пользоваться обожаемым всеми laravel , но меня , увы, бесит вся эта многослойность, куча прибамбасов, которые могут и не пригодиться. Я не могу проследить , что происходит в тот или иной момент в приложении, я не могу понять, что не так, когда постоянно вываливаются 10050 строк в описании ошибки , мне проще создать файл руками , чем специально для этого ставить консоль, и писать php artisan make: ..... меня вполне устраивают возможности CI построителя запросов к БД и мне не нужен "полноценный продвинутый ORM"/ итд итп...
Я пришел к выводу, что мне проще быстро написать небольшой проект на CI , чем пытаться сделать это же "прекрасными" средствами laravel больше двух-трех-четырех недель. Некоторые люди , увы, туго соображают ))))Это я о себе.

Вопрос :

Какие именно критичные вещи есть в CI , которые несовместимы с проектом небольшой барахолки для любителей моделей самолетов? На что обратить внимание и какие дыры нужно специально латать при использовании этого отвелопротивного и мертвого фреймворка?

Спасибо, и да прибудет с вами толерантность !)

РЕЗУЛЬТАТ - на данный момент несовместимых с жизнью аномалий не выявлено. Замечено отставание от модных трендов и неудобство реализации отдельных полезностей.

Comments

[Руслан Полин]

Честно? Ничего плохого нет в его использовании, просто он не модный, как lavarel или yii.

[coderisimo]

Руслан: похоже , что так.)))) И в ситуации , когда мне нужны не "шашечки" а скорее поехать, выбор кажется очевидным.

[Ilya]

Мне тоже непонятны периодические кококо на тему, того, что якобы CI мёртв или плохо работает. У меня за все годы работы на CI не возникло ни одной ситуации, где я бы не решил чисто и грамотно задачу ресурсами CI. Зато он быстр, понятен и предсказуем. И меня, ровно как и вас, от Laravel стало подташнивать со временем.

А пока что ждем релиза 4.0.

Answer 1

[dmitriy]

что бесит в CI:
1. $this->loader->library("lib_name");
- подключение зависимостей происходит через лоадер, любая библиотека, является singliton объектом,это порождает некоторые проблемы в тех местах где нужны новые экземляры, а нужны синглитоны в 2% случаях
- автоподстоновка в IDE не работает
- отсутствие многослойности, мы можем get_instance()->loader->library("lib_name"); сделать в любом месте даже в классе ядра, что позволяет разрабатывать сильно связанный монолитный код
как нужно:
class Controller function __construct(LibName $lib_name){} - все

2. Класс к бд простой query builder, как ни крути в результате много дублирующего кода, - работа с массивами зло, когда строишь приложение и пишешь CRUD справочники например для админки, то придется писать прослойки - CRUD классы, а это тот же Repository, иногда нужно одни и те же модели отделять от слоя хранения а это уже datamapper, и вообще удобно использовать коллекции а не массивы данных получаемых из бд, если все вместе взять то тут и приходит необходимость использовать ORM который имеет под капотом все необходимое.

3. Логгер, ну не psr он, нельзя отказаться от хранилища в файлах и логировать в бд, или выводить на экран в консоль. После использования monolog, логгер CI выглядет убого

4. Миграции, если честно пробовал запускать, работают из браузера, а должны из консоли, можно создать консольные контроллеры с накаткой миграций, но тем не менее приходится много править в миграциях и коде когда меняется структура таблиц, например простейшая задача сменили название колонки, прошлись по коду сменили все использования этой колонки, создали миграцию, изменили модели, если проект большой сделать это не просто. В Propel2 ORM это делается в одном месте в xml конфиге и модели, миграции, перестраиваются одной командой.

5. тесты под капотом они убоги, просто так unit тесты не запустить нужно долго плясать с бубном.
6. Exception просто отсутствуют, работа с исключениями ведется через собственный механизм
7. PSR не используется
8. Работа с конфигами, они разделяются по папкам окружения, не кошерно, особенно когда все добро с доступом к бд комитят в гит, используйте .env

п.с. в новой версии знаю уже многие вещи будут исправлены но тем не менее проще собрать приложения на каркасе https://github.com/mmeyer724/Frameworkless

Comments

[coderisimo]

В 4-й версии обещают много нового. Сейчас частично недостающее можно реализовать, используя сторонние либы. Не запихивать логику в контроллеры, использовать сервисы и репозитории можно даже на codeigniter.

Спасибо за развернутый ответ.

[dmitriy]

в свое время подключил к codeigniter composer и подтянул нужные либы, организовал автозагрузку классов в приложении, CI гулял по приложению в виде DI контейнера, но со временем решил вообще от CI избавиться, теперь это прошлое.

[coderisimo]

diamond: надеюсь, я когда-нибудь дотопаю до таких же выводов). Но тогда это будет естественно и органично. Пока в моей ситуации, увы ,это больше про мышей которые кололись, но продолжали жра... осваивать модные фреймворки )

Answer 2

[kstyle]

php artisan make:auth все же быстрее))

Comments

[coderisimo]

Ага, если вы потом захотите прикрутить подтверждение имэйла перед началом регистрации, и увидите что примеры для 5.2 не подходят для 5.4 ибо структура немного иная - все немного усложняется. А затем вы ищите где прописаны роуты из Auth::routes(); Находите один кусок кода - нет не здесь.. другой... и не здесь.. и вся эта..... х-х-х....ф-ф-ф-фантасмагория происходит постоянно - все уже не кажется таким уж быстрым )))
Я не спорю - laravel крут, просто я - нет )