воскресенье, 21 октября 2007 г.

CodeIgniter vs. CakePHP

CodeIgniter vs. CakePHP

Ниже находится перевод статьи Джонатана Снука (Jonathan Snook) о преимуществах и недостатках двух популярных PHP-фреймворков CakePHP и CodeIgniter.

Прежде чем публиковать такого рода публикации, я обычно опасаюсь всякого рода фанатиков, которые неадекватно реагируют на подобные сравнения. Поэтому стараюсь максимально объективно подойти к повествованию. Все выводы в статье сделаны только на основании фактов.

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





Зачем сравнивать?

CakePHP и CodeIgniter во многом очень похожи между собой, включая то, что оба поддерживают PHP4. Говоря о преимуществах одной платформы, мы тут же можем сослаться на сильные стороны другой.

Они обе дают возможность работать в парадигме MVC-архитектуры, что просто означает их способность разделять Модель (данные), Контроллер (который направляет данные из модели, чтобы получить представление) и Вид (то, что видит пользователь).

Они обе используют роутинг, который даёт возможность привязывать URL к определённой функции внутри контроллера (в CakePHP это называется actions). CodeIgniter поддерживает регулярные выражения для роутинга, в то время как нужно дожидаться релиза CakePHP версии 1.2 для поддержки этой функции. Поправка: CakePHP 1.1 уже поддерживает регулярные выражения для роутинга, но это не отражено в документации.

Они обе поддерживают scaffolding, который помогает автоматически сгенерировать Вид на основании Модели. В CodeIgniter scaffolding упрощён и позволяет получить доступ к подобному функционалу путём добавления ключевого слова в URL. Считаю это недостатком, т. к. часто разрабатываю персональные проекты не для публичного использования, и это ключевое слово надоедает.

Приступим…

Подход к простоте

Я убеждён, что CodeIgniter притягивает благодаря своей простоте. Большая часть работы — это создать контроллер, загрузить библиотеки, получить данные из Модели и отправить результат в Вид. Всё предельно понятно, и вы можете наблюдать, как это работает.

Простота в CakePHP достигается за счёт автоматизации («automagic»). Это делает процесс кодинга быстрым, но без изучения ядра вы просто будете сами себе задавать вопрос «что сейчас происходит?». Что касается меня, то предпочитаю понимать, как всё работает. Начинающих разработчиков этот аспект просто приводит в уныние.

Работа с моделями

Оперирование Моделью в CodeIgniter очень наглядно и позволят применять стандартный SQL в сочетании с некоторыми командами как в этом примере:

$query = $this->db->getwhere('mytable', array(id => $id), $limit, $offset);
$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);
$query = $this->db->get();

Примечание: метод цепочки (chaining), применяющийся во второй части примера, может работать только в PHP5.

Вы также можете создать объект модели, загрузить его и, оперируя различными методами, выполнять определённые задачи. При желании это лучше делать на уровне модели, а не контроллера, чтобы код оставался в рамках MVC.

У CakePHP немного другой подход, который заключается в автоматической подгрузке модели, соответствующей данному контроллеру (контроллеры и модели, имеющие одинаковые имена, связаны между собой). Вы можете отключить эту автоподгрузку и даже указать самостоятельно любые модели, которые должны быть загружены в нужный контроллер.

Кроме того, CakePHP имеет в своём арсенале механизм, помогающий устанавливать связи между моделями, что помогает очень облегчить извлечение данных. Например, находясь в контроллере post_controller, можно сделать следующее:

$this->Post->Comment->findAllByPostId($id)

Я выбрал этот пример, потому что он помогает продемонстрировать две разные концепции. Во-первых, видно, как я получаю доступ к модели комментариев через модель поста (благодаря установленной ассоциации в модели поста). Во-вторых, благодаря методу findAllByPostId CakePHP позволяет извлекать записи из базы через запросы findByX и findAllByX где X — это эквивалент названия поля, откуда делается выборка.

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

$this->Post->findById($id)

Этот запрос даст нам не только публикацию, но и комментарии к ней. Довольно практично.

Валидация

Когда работаете с моделями, вам неизбежно придётся иметь дела с валидацией данных. В CodeIgniter этот функционал представлен классом validation class. С помощью него объявляется набор правил и присоединяется к объекту верификации. Объект валидации автоматически (я предполагаю) проверяет данные, поступающие от URL или формы. Разумеется, здесь вы можете сами определить, как это будет происходить. Validation class может также помочь в процессе определения сообщений об ошибках для того или иного поля.

В CakePHP валидация осуществляется прямо через модель двумя способами. Первый способ производит верификацию всей модели, а второй — каждого поля в отдельности и даёт нам в нагрузку callback beforeSave для определённых полей.

Версия CakePHP 1.2 будет включать в себя переработанную систему валидации, для увеличения гибкости.

Виды

CakePHP сразу включает в себя шаблон по умолчанию и имеет две переменные: title_for_layout и content_for_layout. Любое действие автоматически привязывается к определённому виду (снова «automagic»). И до тех пор, пока вы будете называть ваши файлы особым образом, контроллеры будут автоматически связаны моделями и видами. Соответственно, обойти всё это и определить собственные шаблоны и файлы видов не представляет собой проблемы. К сожалению, нет удобного способа получить сгенерированный код вида, а отсюда и проблемы с реализацией механизма кэширования.

У CodeIgniter подход проще и почти сводится к обыкновенному include’ингу. Каждый файл загружается и обрабатывается. Есть и встроенный шаблонизатор (templating class), но он не проще встроенного обработчика видов (built-in view handling). Вы можете делать на манер CakePHP, постоянно включая в шаблон header и footer, но это будет только внешнее сходство. CodeIgniter позволяет заменить механизмы видов и кэширования сторонними или собственными шаблонизаторами. (И все же Smarty отлично внедряется как в CodeIgniter, так и в CakePHP — прим. переводчика)

Встроенные возможности

CodeIgniter, по моему усмотрению, тут безоговорочно выигрывает, благодаря таким классам, как FTP, Email, File Uploading, XMLRPC, Zip encoding и многим другим.

CakePHP, в свою очередь, может похвастаться обширным репозиторием (the Bakery). Вы можете без труда, как в CodeIgniter, подключить любые необходимые классы. Что интересно: хоть я и не пробовал этого делать, но есть возможность подключать многие классы, написанные для CI к CakePHP.

Автоподгрузка

CakePHP позволяет вносить в приложения обширные изменения путём модификации базового контроллера. Также вы можете создать глобальные методы, используя файл модели, что впоследствии не помешает вам вносить правки уже на уровне контроллера с помощью обратных вызовов (callbacks), таких как beforeFilter, afterFilter и beforeRender. Похожим образом помощники (helpers) и компоненты могут быть подгружены на уровне индивидуального контроллера.

CodeIgniter умеет подгружать помощников, библиотеки и плагины, но делает это глобально для всего приложения. (Здесь автор ошибается, т.к. в CI на уровне контроллера доступна такая конструкция: $this->load->whatever() — прим. переводчика.)

Документация

Документация — это ключ к пониманию любого фреймворка для того, чтобы разрабатывать на нём.

CodeIgniter имеет полный документированный список всех компонентов с каждым из их методов и параметров. У CI есть форумы и wiki с множеством фрагментов пользовательского кода.

CakePHP, в свою очередь, не так хорошо организован. Мануал устаревший и не раскрывает того, что нам предлагает API. Кроме формата оригинальной документации можно получить оффлайн-версию в CHM или PDF. Но всё же у CakePHP есть Bakery с пользовательскими статьями и компонентами. Очень помогает команда разработчиков через IRC каналы (#cakephp at irc.freenode.net). А также довольно активная Google-группа.

Напоследок

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

Я лично остаюсь больше фаном CakePHP, чем CodeIgniter за его «automagic». И это достоинство более явно раскроет себя от версии к версии.

Уточнение

Это сравнение было основано на документации для CodeIgniter 1.5.2 и опыте использования CakePHP 1.1. Я намеренно не стал касаться вопроса производительности, т. к. довольно проблематично подготовить и провести тестирование каждой опции.

Автор: Setti.

Интересное...



Комментарии:


Влад:
21 октября, 2007 в 5:27 пп
Интересно, но не интригующе. Настолько толерантное сравнение, что в результате каждый останется при своём мнении. :)))
Впрочем, автор статьи (Д.Снук) кажется, именно такое, нейтральное «сравнение» и хотел.
Поэтому скорее не CI vs CP, а CI & CP — близнецы братья :)

serega011:
22 октября, 2007 в 4:39 пп
А насчет scaffolding ты уверен в точности перевода, потому что в CI scaffolding это возможность в отображения таблиц БД из любого контроллера по секретному слову + возможность модификации этих таблиц

Anton:
26 октября, 2007 в 3:01 пп
Интересная публикация

larin:
31 октября, 2007 в 1:30 пп
Спасибо, за перевод!
Я тоже как-то пытался сравнивать различные FW, но делал сравнение по большему числу FW, но и более поверхностно.
Но к чему я пришел, так это, что у CI по скорости и простоте нет равных. Этот FW отлично подходит для разработки различных промо-сайтов и других небольших проектов.

jMas:
8 ноября, 2007 в 6:31 пп
Считаю CI лучшим! CMF нового поколения, так сказать, т.к. технология должна развиваться и рости, а не находиться в тупике из-за старой документации.
Это конечно предвзятое мнение, скажите вы. Н, имхо, на то оно и мнение, чтобы, возможно, быть опровергнутым.
Кстати, я не писал на CP, но по внешнему виду кодов она показалась мне сложной. А зачем тебе сложный фреймвёрк, если он должен облегчать работу, что хорошо продемонстрировано в CI.
Плюс скорость работы CI хороша. Говорят, что это эталон скорости.
Вообщем, подведя итоги, скажу, что разработчики CI добросовестно выполнили свои задачи, а именно: упростить создание php-преложений и сделать работу приложения максимально быстрой.

Евгений:
24 февраля, 2008 в 4:55 пп
В новой версии 1.6 в CodeIgniter все сильно поменялось, убрали лапшу из исходников, увеличили скорость и функционал, а так же перевели мануал на русский здесь: ***

Serega011:
18 апреля, 2008 в 7:42 дп
В новой версии 1.6 скорость как раз заметно упала.

Setti:
18 апреля, 2008 в 10:24 дп
Serega011, ссылка на бенчмарки?

Serega011:
18 апреля, 2008 в 10:50 дп
Зачем мне ссылка я переделал большой проект с предыдущей версии на CI 1.6 — в итоге заметно замедление.

Setti:
18 апреля, 2008 в 10:52 дп
Serega011, может быть вы криво переделали?

Serega011:
18 апреля, 2008 в 10:56 дп
Переделка заключалась в добавлении некоторых своих функций в код CI, функции одинаковы что для версии 1.5.4 что для 1.6. Так что проблема(если это конечно проблема) именно в самом фреймворке. Про замедление по сравнению с предыдущей версии были высказывания еще то ли на родном форуме CI, то ли в гугл-группе.


Другие посты по этой теме:



0 коммент.:

Отправить комментарий

Ваш комментарий появится в блоге после проверки администратором