Answer the question
In order to leave comments, you need to log in
What is bad and critically unacceptable in Codeigniter?
I understand that the question is strange, but nevertheless.
Is Codeigniter really dead?
Among cool (or those who want to appear to be) programmers, it is good form to write that this is a dead framework, that it is evil, that it is terrible, etc. In fact, there are a lot of references to it, as one of the 10 (7, 3) of those that are still alive and in use. This is reality.
I honestly tried to use laravel, adored by everyone, but, alas, all this layering, a bunch of bells and whistles that may not be useful infuriates me. I can’t trace what happens at one time or another in the application, I can’t understand what’s wrong when 10050 lines are constantly falling out in the error description, it’s easier for me to create a file with my hands than to put a console specifically for this and write php artisan make: ..... I'm quite happy with the CI capabilities of the database query builder and don't need a "full advanced ORM"/etc etc...
I've come to the conclusion that it's easier for me to quickly write a small CI project than trying to do it the "beautiful" means of laravel is more than two-three-four weeks. Some people, alas, are slow to think)))) This is me about myself.
Question :
What exactly are critical things in CI that are incompatible with the project of a small flea market for fans of aircraft models? What to pay attention to and what holes need to be specifically patched when using this repulsive and dead framework?
Thank you, and may tolerance be with you!)
RESULT - at the moment no anomalies incompatible with life have been identified. A lagging behind fashion trends and the inconvenience of implementing individual utilities have been noticed.
Answer the question
In order to leave comments, you need to log in
what infuriates in CI:
1. $this->loader->library("lib_name");
- dependencies are connected through the loader, any library is a singleton object, this causes some problems in those places where new instances are needed, and singletons are needed in 2% of cases
- auto-substitution in the IDE does not work
- lack of multilayer, we can get_instance()-> loader->library("lib_name"); done anywhere, even in the kernel class, which allows you to develop tightly coupled monolithic code
as needed:
class Controller function __construct(LibName $lib_name){} - all
2. The class for the database is a simple query builder, whatever one may say, as a result of a lot of duplicate code, working with arrays is evil, when you build an application and write CRUD directories, for example, for the admin panel, you will have to write layers - CRUD classes, and this is the same Repository, sometimes you need to separate the same models from the storage layer, and this is already a datamapper, and in general it is convenient to use collections and not arrays of data obtained from the database, if you take everything together, then it becomes necessary to use an ORM that has everything you need under the hood.
3. Logger, well, it’s not psr, you can’t refuse storage in files and log it to the database, or display it on the console. After using monolog, the CI logger looks ugly
4. To be honest, I tried to run migrations, they work from the browser, but they should from the console, you can create console controllers with migrations rolled up, but nevertheless you have to edit a lot in migrations and code when the table structure changes, for example, the simplest task changed the name of the column, walked by code, we changed all uses of this column, created a migration, changed models, if the project is large, this is not easy to do. In Propel2 ORM, this is done in one place in the xml config and models, migrations, are rebuilt with one command.
5. tests under the hood are miserable, just because unit tests cannot be run, you need to dance with a tambourine for a long time.
6. Exception is simply absent, work with exceptions is done through its own mechanism
7. PSR is not used
8. Working with configs, they are divided into environment folders, not kosher, especially when everything with access to the database is committed to git, use .env
p.s. in the new version, I already know many things will be fixed, but nevertheless it is easier to build applications on the framework https://github.com/mmeyer724/Frameworkless
And why are you so clinging to CI, there are a lot of cool microframeworks that are alive (the community is alive and writes packages).
silex.sensiolabs.org
https://lumen.laravel.com/
https://www.slant.co/topics/2642/~php-microframeworks
there is another list here, take any of the living ones and you will be happy.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question