CodeIgniter: Обзор фреймворка для PHP

 codeigniter_logo

Для разработки современных WEB-приложений «голого» языка программирования уже давно недостаточно. Если вы привыкли разрабатывать проекты на php, то вам хороша, известна ситуация, когда приходится писать/переносить кучу повторяющегося рутинного кода для очередного проекта. Из этого положения каждый девелопер выкручиваться по-своему – одни создают свои шаблоны и используют их повсеместно, другие – выбирают всевозможные надстройки для языка – CMF (Content Management Framework).

Почему нужно использоваться фреймворки?

Переходить к использованию фреймворков заставляет не дань моде, скорее это неизбежный шаг, который рано или поздно вынужден совершить любой WEB-программист. Приложения «из браузера» каждый день усложняются, и по функционалу уже давно не уступают многим десктопным вариантам. Разобраться со всеми современными технологиями, используемыми для разработки таких сложных приложений достаточно трудно, а иногда и вовсе невозможно, поскольку появляются они крайне динамично. Чтобы всегда оставаться на коне приходится выбирать CMF, которые упрощают процесс адаптации к новым технологиям. Но не будем петь хвалебных песен CMF, а сразу назовем пять причин, по которым стоит распрощаться со стереотипами и начать использовать фреймворки в своих проектах:

1. Постоянная структура. При использовании фреймворков требуется четкое разделение ролей для каждого файла проекта. Например, если фреймворк построен на архитектуре MVC, то все созданные вами контроллеры, представления и модели будут лежать по разным папкам. При постоянной разработке новых, а также поддержки старых проектов не нужно ломать голову над вопросом: «А куда же я положил такой то сценарий?» или «Где у меня реализована такая-то функция». Кроме того, дальнейшую поддержку таких проектов гораздо проще передавать другим программистам. Ведь чтобы они смогли разобраться в коде и принципах его построения, им достаточно взглянуть на документацию фреймворка.

2. Никаких велосипедов. Пожалуй, каждый программист хоть раз да умудрялся изобрести свой велосипед. Причин может быть много, но самая распространенная – невозможность найти готовое решение. При использовании фреймворков все намного проще, т.к. почти все CMF несут на своем борту кучу библиотек/плагинов с готовым кодом и еще кучу всевозможных полезностей валяются на просторах интернета.

3. Скорость и качество. Самостоятельно решенные задачи решаются не всегда идеально, зачастую полученный результат поддается тотальной оптимизации, но по разным причинам, к ней (оптимизации) прибегают в самую последнюю очередь. Если вообще прибегают. С CMF все проще, поскольку все входящие в него функции тщательно тестируются многотысячной армией программистов (если, конечно, фреймворк популярен) и в случае обнаружения слабых мест, оптимизация последует незамедлительно и более качественное решение войдет в следующую версию фреймворка.

4. Повышение безопасности. При разработке приложений с использованием фреймворков, на порядок повышается безопасность разрабатываемого решения. Практически все фреймворки содержат функции/библиотеки или безопасные классы для решения поставленных задач. Такой подход позволяет избавиться от потерь времени на создание всевозможных проверок и написание соответствующих функций-фильтров, сосредоточившись на логике приложения.

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

Разрешите представить – Code Igniter

За свою практику разработки приложений для WEB мне пришлось перепробовать несколько фреймворков. Некоторые из протестированных мной CMF были чересчур сложны в использовании и изучении (например, фреймворк от Zend) – разработка приложений с помощью таких продуктов не упрощалась, а усложнялась. Усложнения мне были не нужны, поэтому я продолжал искать альтернативу. К счастью она нашлась, – ей стал Code Igniter.


Рисунок 1 (Официальный сайт CodeIgniter)

Возможности CodeIgniter

Code Igniter – бесплатный функциональный фреймворк для php программистов. Среди ключевых возможностей этого продукта можно выделить:

1. Полная совместимость с php 4. Хоть сейчас это не столь актуально, но пару лет назад, когда у большинства хостеров была установлена четвертая версия этого интерпретатора, Code Igniter выгодно отличался на фоне конкурентов. Так, что если вы до сих пор застряли во вчерашнем дне или использоваться php4 вас обязывают другие причины, то теперь вы сможете это делать вместе с Code Igniter.

2. Простой в изучении. Сравнивая Code Igniter с альтернативными решениями можно смело сказать, что он наиболее прост. Помимо хорошо продуманной архитектуры проекта, разработчики не схалтурили и снабдили свое детище отличной документацией. Действительно, документация у CI написана подробно, хорошо структурирована и оперативно обновляется.

3. Безопасность. Проблемы в системе безопасности присущи всем WEB-проектам, однако с CI многие из них решаются автоматически. Например, для точной фильтрации полученных данных на предмет XSS есть встроенная функция, которая позволяет не только удалить, но и сохранить в лог опасные данныеь. Очень удобно.

4. Расширяемость. CI очень гибок и хорошо поддается расширению. Научить фреймворк новым возможностям – пара пустяков. Достаточно подключить нужный плагин/хелпер/библиотеку и начать радоваться новому функционалу. 5. Богатые возможности. Вместе с CI поставляются библиотеки, плагины, хелперы, которые позволяют сразу перейти к решению задач и не заморачиваться изобретением велосипедов. Не нужно заниматься кодокопанием, достаточно воспользоваться специальным механизмом, позволяющим без танцев с бубном «перевоспитать» CI.

6. Active Record. В CI используется модифицированная версия паттерна Active Record Database. С помощью Active Record, работа с базой данных превращается в сплошное удовольствие. Больше не придется писать многочисленные «SELECT» для выбора данных, достаточно лишь воспользоваться методами этого класса, а это всего две небольшие строчки кода. Помимо упрощенного доступа к БД, этот класс позволяет забыть об используемой СУБД. Вы можете построить приложение, используя MySQL, а потом также легко запустить его под Oracle. И это еще не все. Ко всему прочему, AR позволяет хоть немного, но обезопасить работу с СУБД, т.к. при составлении запросов все значения экранируются.

7. Высокая производительность. Столь большие возможности ничуть не повлияли на производительность фреймворка. Работает он действительно шустро. Такое быстродействие достигается за счет очень «легкого» ядра. Все дополнительные библиотеки подключаются лишь по мере необходимости.

8. Архитектура MVC. CI заточен под архитектуру MVC (Model-View-Controller), позволяющую отделить логику от отображения. При работе в команде (программисты + дизайнеры), такой подход будет весьма востребован.

9. Поддержка шаблонизатора. Несмотря, на то, что CI не требует обязательного использования шаблонизатора, при желании им можно воспользоваться.

10. Дружественность к поисковикам. Благодаря своим URL’ам, Code Igniter отлично дружит с поисковыми система и поддается индексации.

MVC

Model View Controller (MVC) – архитектура программного обеспечения, позволяющая разделить модель данных, пользовательский интерфейс и управляющую логику на три отдельные составляющее. Причем разделить ее так, что изменение одного не повлияет на работу других компонентов. Использовать эту архитектуру очень удобно при разработке больших проектов, работа над которыми идете в команде. Например, работая над проектом, программистам не нужно заботиться о будущем интерфейсе. Их цель – получить и обработать данные, а потом отправить их пользователю. Вид, в котором пользователь получит эти данные, программистов волновать не должен. Это уже работа дизайнеров и верстальщиков, которые могут параллельно создавать представления для полученных данных. Что же касается программистов, то они тоже могут распараллеливать свою работу – например, часть разработчиков может сосредоточиться на разработке логике программы, а другая – на проектировании структуры базы данных. Как видно из примеров, при использовании MVC становится возможным распараллелить работу команды, тем самым повысить общую производительность. Итак, MVC состоит из сущностей:

1. Model (модель) – служит для предоставления данных. Как правило, в модели описываются функции, классы для работы с базой данных.

2. View (представление) – отвечает за передачу пользователю обработанных данных.

3. Controller (Контроллер) – занимается интерпретацией запрашиваемых/отправленных пользователем данных, взаимодействует с моделью для их получения. Важно заменить, что Code Igniter, в отличие от других MVC-фреймворков не заставляет использовать MVC в полной мере. Если вам не удобно делить код на три составляющие, то это делать вовсе необязательно. Для создания рабочего приложения вы можете ограничиться одним лишь контроллером, организовав в нем все логику и работу с СУБД. Тем немее, понимание MVC, позволит вам в будущем с легкостью осваивать альтернативные фреймворки (список их можно увидеть в соответствующей врезке).

Установка Code Igniter

Свежий дистрибутив фреймворка вы всегда можете взять с www.codeigniter.com. Разработчики достаточно часто обновляют свой продукт, поэтому я советую подписаться на RSS и постоянно быть в курсе всех последних изменений. Итак, предположим, что вы скачали дистрибутив фреймворка. Теперь можно распаковать архив в папку DocumentRoot web-сервера Apache. Вследствие этих нехитрых действий фрейморк становится готов к работе, в чем легко можно убедиться, зайдя на ваш сайт. Если фреймворк работает успешно, то в браузере появится картинка примерно такая, как на рисунке 2.


Рисунок 2 (Фреймворк готов!)

Базовая настройка

Пока работоспособность фреймворка не представляет ничего интересного (такое окно и средствами php недолго вывести), поэтому двинемся дальше и посмотрим на структуру каталогов, которая у нас получилась после распаковки файлов дистрибутива. В корне папке Document Root у нас появилось два каталога и один файл (index.php). Откроем этот файл в php редакторе. Настройки этого файла влияют на работу всего проекта, созданного на основе CI.

Итак, давайте посмотрим на наиболее важные переменные, доступные для изменения в этом файле. $sytem_folder – название и путь к папке, содержащей все внутренности CI. $aplication_folder – путь к папке с приложением. Значение этих переменных можно оставить по умолчанию, но при использовании CI в реальных проектах я вам рекомендую переименовать эти папки и изменить путь. Это необходимо делать в целях безопасности. Незачем никому знать в какой папке вы храните файлы вашего приложения. По своему опыту работы с этим фреймворком, я рекомендую создать отдельную папку, в которой вам предстоит хранить все свои проекты. Например: project/application1, prroject/application2.

Таким образом, вы сможете на одной копии фреймворка создавать и поддерживать несколько отдельных проектов. Помимо изменений путей к папкам, в файле index.php вы также можете изменить вид отображения ошибок (error_reporting()). По умолчанию будут отображаться все ошибки, но опять же, в реальном приложении лучше ничего не отображать. Теперь перейдем в папку приложения – system/application. В ней содержится несколько каталогов:

/config – здесь хранятся все настройки для текущего проекта.

/controllers – в эту папку нужно сохранять все созданные вами контроллеры.

/error – шаблоны для страниц-ошибок.

/helpers – папка предназначена для хранения созданных вами хелперов.

/hooks – директория для «ловушек».

/language – папка для хранения языковых файлов.

/libraries – все созданные вами библиотеки должны быть здесь.

/models – папка с моделями данных.

/views – директория для хранения представлений вашего проекта.
Изучая дерево директорий проекта Code Igniter, вы наверняка обратили внимание на незнакомые названия. Чтобы не путаться и говорить друг с другом на одном языке, давайте дадим им определения. Итак, в платформе CI, существуют следующие сущности:

Helpers (Хелперы) – коллекции функций. В каждом вашем проекте может возникнуть необходимость объявить что-нибудь специфическое. Вот все эти функции лучше всего объявлять в хелперах. Для удобства использования, хелперы обычно группируют по входящим в них функциям. Например, файловый хелпер, в него входят функции для работы с файлами.

Hooks (Ловушки) – встроенная в CI технология, позволяющая изменить поведения работы фреймворка без внесения изменений в ядро. Libraries (Библиотеки) – ваши собственные классы. Все свои классы, выполняющее универсальный код, в CI принято определять как библиотеки.

Практика

Чтобы продемонстрировать реальные возможности Code Igniter, я решил на практике рассмотреть процесс создания такого популярного сервиса как «Блог». Сегодня вести блоги чрезвычайно модно, поэтому пример весьма актуален. Итак, приступим. Первым делом подготовьте фреймворк к работе – распакуйте его дистрибутив в папку DocumentRoot WEB-сервера Apache.

Откройте файл /system/application/config/config.php, найдите в нем определение base_url (базовый урл) и укажите полный путь к папке, в которой расположен CI. Если вы распаковали его в корень директории DocumentRoot и будете разрабатывать проект на локальной машине, то просто укажите здесь: http://127.0.0.1. Все, больше нам config.php не понадобится и потому его можно закрывать. Теперь нам нужно определить контроллер, который будет загружаться по умолчанию (т.е. когда пользователи будут обращаться к http://127.0.0.1).

Несмотря на то, что мы еще ничего и не создали, но скоро точно создадим, а создадим мы контроллер с именем Blog, поэтому давайте сразу пропишем к его в маршрут по умолчанию. Все маршруты описываются в файле routes.php, который расположен в папке config. Открываем этот файл, находим $route[‘default_controller’] и присваиваем ему значение Blog. Сохраняем. При разработке нашего первого проекта, нам потребуется возможность обращаться к разным хелперам. Поэтому нам необходимо указать, чтобы эти хелперы запускались автоматически (хотя их инициализацию можно производить прямо в коде). Чтобы определить объекты, которые должны инициализироваться при старте, нужно отредактировать еще один файл настроек – autoload.php. Откроем этот файл и найдем секцию, в которой происходит описание автозагрузки хелперов (Auto-load Helper Files). Следуя шаблону из комментария, опишеме следующие хелперы: html, url, typography.

На этом можно считать, что базовые настройки мы сделали. Сейчас остается лишь установить настройки для соединения с базой данных, после чего сразу перейти к разработке. Все настройки подключения к базе данных хранятся в файле database.php. Откроем его и пропишем все необходимые настройки. Я не буду комментировать редактирование этого файла, т.к. сложного в этом ничего нет, и если вы хоть раз работали с базами данных, то проблем возникнуть не должно.


Рисунок 3 (Разработка в самом разгаре)

Создаем базу данных

Для сегодняшнего примера нам потребуется база данных. В ней мы будем хранить все топики блога, а также комментарии оставленные пользователями. Имя базы вы должны были уже выбрать (когда настраивали соединение), теперь вам нужно ее создать физически. В своем примере я использую базу данных с именем test и содержащую две таблицы:

1. tblcomments – комментарии, оставленные пользователями:

2. tblrecords – таблица будет содержать все записи блога:


Рисунок 4 (Макет базы данных)

Готовим модель

Итак, создадим новый файл для будущей модели, перепишем в него код из первого листинга, сохраните в файл mblog.php:

Листинг 1. Модель

Описание любой модели в CodeIgniter начинается с определения нового класса-наследника от Model. Самое первое, что я делаю после объявления класса – вызываю конструктор. Обратите внимание, что для определения конструктора я использую функцию с именем таким же как и у класса. Этот метод используется в php4, а для php5 мы должны использовать __contruct(). По идее, для этой модели нам не нужно использовать конструктор, его объявление я привел только для демонстрации. Когда в реальном приложении вам потребуется описать конструктор, то не забудьте в самом начале указать parent::Model. Это необходимо делать для того, чтобы, конструктор вашего класса не перекрывал конструктор класса Model.Итак, давайте взглянем на функцию с именем get_last_record();. В первой строчке тела этой функции я обращаюсь к классу db и вызываю функцию order_by(). Эта функция позволяет установить оператор ORDER BY для будущего запроса. В качестве параметров, функции нужно передать:

– поле, по которому нужно упорядочить данные – направление упорядочивания. В блогах принято, чтобы новые записи были в самом верху, поэтому в качестве имени поля я передаю «date», хранящий дату публикуемого топика, а во втором параметре указываю desc (по убыванию). Установив Order by, можно смело выполнять запрос. Для простого получения данных в AR есть метод get(), который принимает два параметра:
– имя таблицы, из которой выбирать данные
– количество записей для выборки

Думаю, с выборкой данных все понятно и вы уже смогли прочувствовать прелести использования ActiveRecords, теперь давайте взглянем на то, как делается добавление новых записей в таблицу. А делается она очень просто. Для вставки используется метод insert() класса db. Методу нужно передать всего лишь два параметра:

– имя таблицы
– массив данных, в котором ключ – это имя поля в таблице

Делаем контроллер

Мы создали модель, теперь нам предстоит создать контроллер, который сможет плодотворно с ней работать. Создайте новый файл и перепишите в него код из листинга 2. Хочу сразу предупредить, что во втором листинге приведен лишь отрывок кода, полный исходный текст вы можете получить по ссылке в конце статьи.

Листинг 2. Контроллер.

Первое, с чего начинается новый контроллер – с описания нового класса-наследника от Controller. Для нашего примера я объявил класс Blog. В самом классе, нам нужно описывать функции, имена которых будут с url’ами. Например, объявив функцию foo(), и обратившись по адресу http://localhost/index.php/blog/foo мы спровоцируем ее выполнение. Но вернемся к нашему листингу. Сразу после описания класса, у меня идет объявление функции index(). Функция с таким именем будет автоматически вызывать при обращении к нашему контроллеру (http://localhost/index.php/blog).

В теле этой функции, я в первую очередь инициализирую созданную нами модель. Для инициализации используется loader load -> model. В качестве параметров я передаю ему имя созданной нами модели и также значение true, указывающее на то, что установка с БД должна произвестись автоматически. После инициализации модели я сразу обращаюсь к одной из ее функций – get_last_record().

Как вы помните, после выполнения, эта функция возвратит все имеющиеся в ней записи. Полученные данные нужно отправить пользователю, для этого я загружаю представление vblog. Для загрузки представлений используется конструкция load -> view(). Из параметров нужно передать:

– Имя представления
– Данные, из которых будет формироваться страница для пользователя.

Пример исходного текста представления вы можете посмотреть в листинге 3. Я не буду подробно расписывать содержимое листинга, поскольку все, что в нем происходит – печать данных стандартными средствами php. Единственное, что нуждается в объяснении – получение имен переменных. Как ты помнишь, при вызове представления, в качестве третьего параметра мы передавали массив с данными. Получение значений осуществляется через переменные, имена которых равны именам ключей передаваемого массива. Например, если у нас есть массив array с ключом sample ($array[‘sample’]), то для того, чтобы получить доступ из представления к значению sample, нам нужно из представления всего лишь на всего обратиться к переменной $sample.

Листинг 3. Первое представление

Тестируем пример

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


Рисунок 5 (Блог в действии)

Некрасивые url

Посмотрев наш «блог» вы наверняка заметили в адресной строке url вроде http://localhost/index.php/blog. Такой url выглядит ужасно и совершенно не годится для реального проекта. Для улучшения внешнего вида url, я рекомендую вам воспользоваться возможностями плагина mod_rewriter WEB-сервера Apache. С его помощью вы быстро приведете url к должному виду.

Заключение

К сожалению, рассмотреть все возможности Code Igniter в рамках одной статьи просто-напросто невозможно, да и не нужно. Моя цель была рассказать вам про такой интересный продукт как Code Igniter и я думаю, что эта задача выполнена. Все, что сегодня осталось за кадром, вы всегда сможете почерпнуть из официальной документации. Мне остается пожелать вам только удачи!