CodeIgniter как первый фреймворк

Как только в среде php-шников упоминают о использовании фреймворка CodeIgniter, сразу начинаются шутки насчет «закопать труп» или «закопать стюардессу». Спектр мнений на этот фреймворк большой, но почему-то все говорят, что его не стоит изучать и далее выводят огромный список пунктов почему. Вот только я читаю и слышу эти мнения где-то с 2012 года.

История вопроса

Нет, пересказывать статью из Викепедии я не буду. Однако отмечу, что фреймворк этот разрабатывался не просто как этакий «сферический конь в вакууме», а конкретно под разработку платного движка Expression Engine коммерческой фирмой.

Тогда это был мейнстрим и все лучшее методы программирования были в движке.

19401_4ff6_8

Но много воды утекло с тех пор. Фирма довольно прохладно относилась к низовой инициативе развития движка, поэтому были форки (ответвления) — Kohana, FuelPHP и другие менее известные.

В 2014 году фирма EllisLab приняла решение отдать проект в добрые руки, поскольку ей самой он был как чемодан без ручки: и бросить жалко, и нести тяжело. В 6 октября было объявлено о передаче всего и вся Технологическому Институту Британской Колумбии.

Ну а год назад вышла версия 3.0, где были пофиксены куча багов с сессиями, улучшили шифрование и так далее. Но революционного прорыва не было — это все тот же CodeIgniter. Но лицензия уже не GNU, а MIT. 11 марта 2016 года вышла минорная версия 3.0.5, а совсем недавно 21 марта 2016 года вышла 3.0.6. Так что фреймоворк живет, хоть и не процветает.

Чего с ним все так носятся?

CodeIgniter был в свое время эталоном самого понятия фреймворк: MVC, минимум необходимого и полная свобода действия. Остальные крупные фреймворки были огромными комбайнами, где было все и много, но которые сложно было понять и сложно было начать с ними работать.

Сам CodeIgniter позиционируется для маленьких и средних сайтов. В принципе, таким он и остался. И сейчас на нем легко накидать основу сайта, даже довольно разветвленного и затем уже заниматься его допиливанием.

Так же за годы работы с ним накопилось огромное количество подробных мануалов, видео и отличных практик. Но, в основном, на английском языке.

На CodeIgniter были разработаны куча сайтов и куча CMS: ImageCMS, MaxSite, PyroCMS (сейчас на Laravel перенесена), ExpressEngine. Это только крупные проекты, которые «взлетели». И куча более мелких.

Но с другой стороны, EllisLab прохлопала ушами развитие ООП в  php и очень долго не включала всех возможностей в фреймворк. Именно для этого проект переписали для ООП и назвали Kohana.

Так же и сейчас в CodeIgniter отсутствует стандарты php PSR-0, PSR-1, PSR-2, PSR-3, PSR-4 напрочь.

Однако это совершенно не мешает разрабатывать сайты! И как бы его не хоронили, он живее всех живых. Сейчас идут разговоры о ветке 4, где многие провальные вещи будут подтягивать до современных стандартов. Будем посмотреть (с) Гоблин ака Пучков.

Что есть в CodeIgniter

Во фреймворке есть все самое необходимое: гибкий роутинг, работа с базами данных через PDO ActiveRecord, валидация форм, кучу хелперов для работы с изображениями, сессиями, кешем, строками и так далее. В принципе, это все и есть самое необходимое для написания сайта без написания костылей и велосипедов.

В 2011 году появились миграции баз данных, но реализовано это очень костыльно и есть куча подводных камней. На мой взгляд, уж лучше руками писать SQL запросы. В любом случае, фреймворк CodeIgniter не предназначен для крупных проектов, так что даже в маленькой команде можно договориться как и что сделать с базой без всяких проблем.

Сторонние библиотеки тоже есть, которые очень расширяют ядро фреймворка: есть реализация паттерна HMVC, есть работа с пользователями ACL и куча других возможностей. Но их нужно гуглить.

А нет во фреймворке неймспейсов и автозагрузки классов. Что, с другой стороны, позволяет не грузить автоматом все подряд и раздувать память, а делать лишь то, что нужно. Поэтому CodeIgniter и лидирует по производительности, уступая лишь Phalcon.

Нет и даже самой плохенькой ОРМ, только ActiveRecord, где запросы формируются в ООП-стиле, но руками.

Нет и composer из коробки в отличие от современных движков. Хотя подключить его дело пары минут и куча готовых пакетов можно легко интегрировать в проект. Так можно прикрутить шаблонизатор Blade, ОРМ Eloquent, библиотеку Facker, логеры, дебагбары и так далее.

Нет во фреймворке и middleware, ServiceProvider, которые применяются в Laravel и других движках.

Подведя итоги, можно сказать, что фреймворк смотрится очень минималистично по современным меркам, однако все самое необходимое в нем есть.

В чем прелесть CodeIgniter

Как ни посмотришь книжку о php — все очень устарело по ООП, отсутствие живых примеров. Нет, база есть везде: наследование, полиморфизм, области видимости и так далее есть. А вот многие фишки типа неймспесов, сложных шаблонов middleware, ServiceProvider на русском языке вы не найдете.

А вот в CodeIgniter всего этого не нужно. Почти, потому что если вы начнете пользоваться пакеты composer, то придется и это осваивать. И это дает более легкий уровень вхождение в мир программирования на php.

Нет ОРМ — значит вам придется самостоятельно писать запросы руками. И писать в модели свой код, не надеясь на код из ОРМ, который наследует модель. Это камень в огород Laravel: там даже в крутых видео уроках в модели только ссылка на таблицу, правила валидации и может быть связи один-ко многим и многие-к многим.

Нет (или почти нет) миграций — изучай SQL и пиши на нем запросы по созданию или изменению баз данных. Заодно и про индексные файлы почитаешь, подумаешь как оптимизировать базу. А то в Laravel Schema делает все за тебя. Нет, можно её прикрутить и в CodeIgniter, но когда разберешься с этим, то уже и не нужно будет эта плюшка.

Нет шаблонизатора? Так php писался именно как шаблонизатор для веба, а не как язык программирования. И вместо фигурных скобочек можно легко прописать теги php, чуть большим количество символов. Ну или прикрутить тот же Blade или Twig в проект.

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

Нет и возможности работать с командно строкой как Artisan. С одной стороны это хорошо: вы будете сами генерировать код. А с другой стороны только кодогенерацией командный менеджер не ограничивается. Это все роуты, и выполнение кода фреймворка, и сервисные функции. Увы, чего нет, того нет.

Так что для учебных целей и маленьких проектов CodeIgniter прекрасный выбор, кто-бы что не говорил!

Стоит ли применять CodeIgniter в серьезной разработке

А вот если вы фрилансер и начинаете проект коммерческий и больше сайта-визитки, то тут нужно хорошо подумать, прежде чем начинать его на CodeIgniter.

Дело в том, что у того же Laravel есть куча пакетов, построенных на новейших принципах php, которые не поддерживает CodeIgniter. И применить их будет сильно затруднительно именно на CodeIgniter. Это и дебагбары, и заготовки админки, и заготовки галерей и много чего еще.

Фактические, сейчас разработка идет к тому, чтобы брать готовые проверенные пакеты и из них как из кирпичиков собирать проект. А дописывать лишь уникальный функционал. Такую идею усиленно муссировали в 2014-2015 годах, когда чуть ли не объявляли любой фреймворк как пережиток прошлого, а каркас приложения собирался из пакетов composer от роутинга до админки. Я считаю, что это недостижимая мечта, по крайней мере сейчас. Но пользоваться готовыми наработками стоит.

Именно в количестве готового CodeIgniter сильно уступает тому же Laravel. То есть база-то есть, а вот «мясо» придется писать самостоятельно.

Вот простой пример: нужно сделать форму добавления новости и там есть такая штука как slug или url, который обычно формируется из транслитерации заголовка. Гляньте в WordPress на добавления статьи и вы поймете о чем я. Так вот, можно эту функцию написать самому, а можно взять готовую из composer и обернуть её в javascript, чтобы при потере фокуса поля заголовка новости автоматом сформировался slug. Мелочь, не правда ли? А попробуйте решить эту проблему самостоятельно, учтя не только русский язык (значит нужно куча таблиц транслитерации), замена пробелов на дефис или нижнее подчеркивание (а как настраивать это?), ограничение по длине знаков (если нужно) или перевод на английский слов (значит по API на гугл.транслейт или переводчик Яндекса нужно отправлять и забирать готовое).

А галерею фотографий сделать с нуля? Можно самостоятельно. А можно взять готовую. Даже самостоятельно сделав, после недели мучений (ну или несколько дней — в зависимости от вашей квалификации), вы явно захотите её использовать повторно. А как это оформить, чтобы можно было использовать в другом проекте с минимальными переделками? По хорошему, это называется «модуль» в Kohana — модель-вид-контроллер, обособленные от приложения. Со своими настройками, своими инсталятором (таблицу же нужно сделать сначала), своей удалялкой. Делать пакет для composer?

Так что если вы уверены в своих силах, вы не будете использовать (или использовать по минимуму) чужие модули/пакеты, то можете сделать проект на CodeIgniter. Особенно, если вы долго работаете и у вас куча своих наработок. Но тогда почему вы читаете эту статью?!

В любом другом случае стоит выбрать другой фреймворк.

А как же ты? Будешь ли изучать и использовать CodeIgniter?

Лично я сейчас его изучаю с прицелом на будущее — жду версию 4.

CodeIgniter очень хорошая ступень для изучения  программирования на php и вообще принципов построения приложений для web.

Для себя я нашел в нем простоту, которая мне нравится. Мне понятен код с готовых приложение на github без всякой магии, в отличие от Laravel (там постоянно всё пытаются запихнуть в ServiceProvider  и в middleware).

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

А в тех местах, где фреймворк слаб, остается как раз место для изучения новых вещей и расширения границ — MySQL, паттерны проектирования.

Кстати, по весу архив с CodeIgniter без документации весит всего 693 Килобайт. А Laravel 5 весит в архиве под 6 Мегабайт. Вот и вопрос по производительности: 0,05 с и 1,8 Мб памяти у одного, и 0,5 c и 8 Мб памяти у другого. Говорить, у кого какие показатели, думаю излишне.

Но и Laravel тоже не думаю бросать изучать — это новые подходы, новые горизонты. И, как мне сказал один из старших товарищей, совсем другие деньги за работу.

Какую IDE лучше для CodeIgniter?

Казалось бы, простой вопрос. А на него нет простого ответа.

Если для Laravel однозначно лучше PHPStorm и только он, то для CodeIgniter не все так однозначно.

Уже только самый новичок не слышал, что в Laravel все делается на фасадах и потому ломается автокомплит. Из-за этого и ставят пакет ide-helper, который по сути является закоментированный файл с описанием в комментариях свойства и методов всех классов.  В CodeIgniter этого нет, это няшный сторый ООП. Но автокомплит срабатывает на стандартные функции фремворка, а вот на ваши модели может и не сработать.

Так что все IDE находятся  в одинаковом положении. Есть некоторые способы обойти эти косяки через похожий хелпер под CodeIgniter, но его автоматом не генерируют, а придется самостоятельно добавлять.

Оказалось, что лучшей IDE является один из аутсайдеров —Codelobster с плагином для CodeIgniter. Тут самый лучший автокомлит для этого фреймворка, он самый быстрый (написан на С++), сам редактор самый маленький. Но и недостатков в нем тоже хоть отбавляй. Хорошо хоть косяки со шрифтом редактора подправили.

Думаю, что я напишу отдельную статью об этом редакторе.

Нет, не напишу. Редактор простой, глючный. Кроме как для CodeIgniter преимуществ перед другими у него нет. ИМХО.

Ну а на сегодня все. Только пожалуйста, не нужно начинать флеймить в комментариях про «трупы» и «стюардессу». Хотя аргументированное мнение я с удовольствием выслушаю от оппонентов :).

Ссылка на основную публикацию