Почему нужно использовать php-framework’и, на примере codeigniter

    Навеяло вчерашним ночным разговором в асе с одним недопрограммистом. Узнав, что я использую в своих проектах codeigniter, он усомнился в моем профессионализме… И, насколько я понимаю, это не только его мнение, многие не признают framework’и, и скажу вам, что это не от большого ума! Взять например windows-программистов, почему им некто не советует писать на чистом паскале, вместо Delphi, и как так получилось что си-шники используют visual studio? Сегодня я расскажу тебе о пользе php- framework’ов, на примере любимого мною codeigniter’а, выделю основные достоинства такого метода программирования, расскажу о том, насколько легко его изучить, и покажу где почитать подробнее.

    Прежде чем начать


    • Внимание! Важно понять, что codeigniter облегчает жизнь только тем программистам, которые на хорошем уровне знают сам php! Если ты только начинаешь программить, то пока учись…
    • Codeigniter реализует только основные функции, например работу с БД, ЧПУ, постраничный вывод записей, вывод календаря, upload файлов… То есть самые распространенные, большинство функций тебе все равно придется писать самому.
    • Codeigniter не делает за тебя твою работу, он только помогает тебе… по мере возможностей…


    Почему следует использовать codeigniter.


    В жизни каждого программиста, наступает момент, когда на первый план выходят скорость и качество разработки. Это означает, что программист стал профессионалом. То есть я уже не могу дать кому нить из друзей ссылку на свой последний проект, и сказать «Смори, какой ЧПУ я реализовал в проекте», потому как, этот ЧПУ за меня реализовал codeigniter, зато я сэкономил пару тройку часов, кучу нервов, и уверен в качестве реализации. Так чем же хороши framework’и в целом, и codeigniter в частности?
    • Позволяет не заморачиваться на мелочах, и сосредоточиться на логике проекта.
    • Экономит кучу времени
    • Все твои проекты будут иметь одну и ту же структур у файлов, что отметает вопросы типа: «Блин, куда же я закинул конфиг для БД, пол года назад, когда писал этот гребанный скрипт?!»
    • Многие функции в нем реализованы грамотнее, чем ты бы реализовал их сам.
    • Расширяемость. Если тебе нужна реализация какой то функции, и тебе лень писать ее самому, высока вероятность что ты найдешь нужный плагин к codeigniter’у на просторах инета. Так же если у тебя есть своя реализация нужной тебе функции, которую ты постоянно используешь в своих проектах, ничего не мешает тебе оформить ее как плагин (Хелпер).


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

    Переход на codeigniter


    Многие программисты бояться всего нового, ибо освоение новой технологии занимает время, лучше уж старое, но привычное, чем новое, неизведанное и не всегда лучшее. Скажу сразу, codeigniter – это лучше, а его изучение у меня заняло не больше дня. Тут, надо заметить, что речь идет именно о codeigniter’е, т.к. на освоение zend’a уйдет гораздо больше времени. Перенос на codeigniter своей Cms занял у меня всего пару дней, и это, само собой, стоило того!

    Заключение


    «Ну и чо? Он совершенно не раскрыл тему! Ни строчки кода! Ни одного конкретного примера! Чо за нах! Пойду в гугл, пробью поподробнее, чо за codeigniter…»
    И если это твои мысли, то я своего добился. Целью этой статьи не было научить тебя программить на codeigniter’е, я хотел тебя просто заинтересовать, рассказать тебе про эту технологию, а научат тебя другие сайты:
    http://code-igniter.ru/ — CodeIgniter по-русски.
    http://codeigniter.com – Официальный сайт.

    Программируйте умно.
    Ваш voff.
    Поделиться публикацией

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

      +3
      Вставьте вместо CodeIgniter cakePHP и это будет про меня. Я бы еще добавил пункт — это приучает к coding standarts (ну в рамках фреймвокра то точно), а это тоже не хилый плюс.
        0
        так действует любой фреймворк — он вгоняет тебя в определенные ограничения, но взамен получаешь несомненно больше.
        0
        >что codeigniter облегчает жизнь только тем программистам, которые на хорошем уровне знают сам php!
        Имхо если чел. чуть-чуть понимает что такое ООП разобраться в ci проблем нет. Но если он не понимает что такое ООП то и программистом его назвать сложно. Все-таки 2008 год на дворе.
          +1
          Конечно понятие ООП безусловно нужно, но и сам голый PHP хорошо знать обязательно.

          А вообще основное приемущество фраемворков, лично для меня, не нужно заморачиваться над мелочами, которые делал раньше из проекта в проект. Остаётся больше времени на проектирование логики приложения, что куда более интересно, чем «тупой» кодинг.
          • НЛО прилетело и опубликовало эту надпись здесь
          +2
          Да уж… Надо обязательно сперва самостоятельно изобретать свой велосипед, чтобы потом по достоинству оценить фреймворки.
          Пошел разглядывать CI, пора уже делать шаг на следующую ступеньку.

          PS. Капнул чутка благодарности за толчок в нужную сторону.
            0
            Правильные мысли, тоже собираюсь переходить на CI и Zend Framework.
            Хотя сказать по правде, в силу специфики размеров проектов, с которыми работаю, как правило фреймворк не применим в большинстве случаем и для каждого проекта создаётся костяк на базе идейной структуры, обеспечивающей работу с сессиями, загрузку модулей, ЧПУ и некоторые самые базовые вещи. Всё остальное module specific или пишутся классы для работы с конкретными вещами (как правило, они reusable)
              +7
              code-igniter.ru/user_guide/libraries/table.html
              $tmpl = array (
                                  'table_open'          => '<table border="0" cellpadding="4" cellspacing="0">',
              
                                  'heading_row_start'   => '<tr>',
                                  'heading_row_end'     => '</tr>',
                                  'heading_cell_start'  => '<th>',
                                  'heading_cell_end'    => '</th>',
              
                                  'row_start'           => '<tr>',
                                  'row_end'             => '</tr>',
                                  'cell_start'          => '<td>',
                                  'cell_end'            => '</td>',
              
                                  'row_alt_start'       => '<tr>',
                                  'row_alt_end'         => '</tr>',
                                  'cell_alt_start'      => '<td>',
                                  'cell_alt_end'        => '</td>',
              
                                  'table_close'         => '</table>'
                            );
              
              $this->table->set_template($tmpl); 
              

              Это, простите, здец…
                0
                Это не здец, а шаблон таблицы, и по хорошему его либо вообще трогать ненадо, либо измеить один раз, то что нужно. Вы пытаетеся найти недостатки, забивая на достоинства.
                  +6
                  я не вижу в таком подходе к шаблонизации ни одного достоинства.
                  сплошные недостатки.
                    0
                    Если вы читали введение к фреймворку — там написано, что шаблонизатор присутствует, но он СОВСЕМ НЕОБЯЗАТЕЛЕН.

                    Как говорится, не нравятся стринги — не носи их :)
                      +1
                      дело в том, что даже если плохая вещь необязательна, лучше она от этого не становится.
                      0
                      CI не навязывает шаблонизаторы. Не нравится этот, возьмите любой другой.
                      Или радикально прикрутите XSLT. Это еще проще.
                      0
                      Скажите вот что — в приведенном IntenT примере без копипастинга $tmpl можно обойтись или нет?
                        0
                        Можно, уже вижу. Тем не менее, целесообразность абстрагирования от HTML-таблиц от меня как-то ускользает.
                          +3
                          Так вот — управлять отображением таблиц в контроллере — это, извините, таки здец.
                            –1
                            Если честно, шаблонизатор в ci действительно простейший, лично я пользую smarty.
                              0
                              угу…
                                0
                                CodeIgniter обладает рядом значительных плюсов перед другими веб-фреймворками, например:

                                * используется модель MVC (Модель-Отображение-Контроллер), хорошо зарекомендовавшая себя при разработке приложений самой разной направленности;

                                это про реализацию отображения в контроллере
                          0
                          Использование фреймворков — это хороший шаг, который позволяется сосредоточиться на написании бизнес-логики вашего приложения, вместо реализации велосипедов. Но иногда вместе с этим приходят и проблемы: вы не до конца понимаете, как оно работает (в случае «жирных» фреймворков типа symfony), встречаются проблемы с производительностью.

                          В начале статьи вы немножко бредите, приводите совсем непонятную аналогию с Pascal и Delphi, а еще зачем-то примешали C и IDE Visual Studio…
                            +1
                            у меня есть свой велосипед, и другие велосипеды я смотрю только ради их изучения и дальнейшей модернизации своего велосипеда…

                            на счет «Все твои проекты будут иметь одну и ту же структур у файлов, что отметает вопросы типа: «Блин, куда же я закинул конфиг для БД, пол года назад, когда писал этот гребанный скрипт?!»» и «Многие функции в нем реализованы грамотнее, чем ты бы реализовал их сам.» не согласен… пусть мои проекты — мелкие и вообще кака полная, но у них у всех схожая структура и при разборке в скриптах годичной давности проблем не возникает, а на счет функций, все мы люди и все иногда пишут хрень…
                              +1
                              и еще, я использую сторонние фреймворки, но только те которые помогают создать гуи (например Qt, JQuery)
                              0
                              Сам юзаю CI, но подумываю о переходе на другой фреймворк по одной причине — CI до сих пор ходит под 4-м пхп. А так уже без CI чувствую себя неуютно. Я готов им пользоваться уже только за его ф-и работы с БД. Как-то так…
                                0
                                С CI часто уходят на kohana, которая работает только с php5.
                                Правда у нее очень большие проблемы с документацией(!) и обратной совместимостью со старыми версиями, т.е. обновиться весьма проблематично.
                                  0
                                  надо будет поглядеть, хотя проблемы с документацией это неайс.
                                  А вроде еще ZF на пхп5.
                                  0
                                  А вы не обращали внимания на то, что там же две ветки кода?
                                  Если на сервере установлена пятёрка, то задействуется одна ветка, в противном случае другая.

                                  if (floor(phpversion()) < 5)
                                  {
                                  load_class('Loader', FALSE);
                                  require(BASEPATH.'codeigniter/Base4'.EXT);
                                  }
                                  else
                                  {
                                  require(BASEPATH.'codeigniter/Base5'.EXT);
                                  }

                                  Ничто не мешает выкинуть Base4.php и самому писать только из расчёта на пятёрку.
                                  0
                                  Извините, но Visual Studio — это среда разработки и инструментальные средства, а Delphi — это среда разработки и язык программирования, но никак не framework. Так что сравнение не очень удачное…

                                  Скорее нужно привести пример всякие библиотеки и компоненты, которые программисты на VS и Delphi используют.
                                    +1
                                    Наверное, имеется в виду vcl, которая — неотъемлемая часть ide delphi и «языка delphi» (я в курсе, что язык называется object pascal), и которую вполне можно назвать фреймворком.
                                    +2
                                    Я взял от CI:
                                    1) подхватывание контроллеров из ЧПУ + возможность ре-роутинга урлов,
                                    2) обертку над БД (пишу чистый SQL, active record не использую)
                                    3) классы для логирования и профилирования

                                    С этими вещами еще не разбирался, но выглядят привлекательно:
                                    4) примочки типа базового фильтрования на предмет xss, простой типограф, еще некоторые хелперы
                                    5) классы для доступа к ftp и xml-rpc
                                    6) классы для отправления email, работы с сессиями, работы с календарем
                                    7) класс-листалка, класс-простенький манипулятор над изображениями

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

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

                                    Чего мне не хватало и я написал это сам:
                                    1) реализация паттернов Registry и IdentityMap
                                    2) мне нужны data-mapper`ы, как раз над ними работаю
                                    Врезать в CI свою функцию __autoload() не составило никакого труда, так же как и пользоваться своими классами, сложенными в отдельную папочку рядом с CI. Писать свои классы как CI-библиотеки или плагины нет никакого желания, пусть они будут от него независимыми.

                                    Итог:
                                    1) CI дал мне несколько удобных вещей, которые мне пришлось бы реализовывать самостоятельно. Вещи эти достаточно базовые и пере-затачивание их от проекта к проекту не требуется
                                    2) необходимые вещи я спокойно добавил в CI, трудностей не возникло
                                    3) в CI есть вещи, которые мне не нужны или не устраивают меня, или даже бесят, но они лежат себе в файликах и меня не колышат.

                                    Вывод:
                                    CI вам предоставляет свой инструментарий но не ограничивает вас в его расширении сторонними разработками. Пользуйтесь ровно тем, что вам надо, на остальное забейте.
                                      0
                                      Вот лично меня, поддержка усопшего PHP4 отталкивает очень сильно от «поджыгателя» не понимаю необходимости писать костыли, выворачивать код на изнанку, отказываться от паттернов и множества других необходимых для комфортной и удобной разработки средств PHP5, а также от множества функций появившихся в 5-ке, зачем?
                                      Большинство хостингов либо уже давно имеет в списке PHP5 либо и все равно придется в ближайшее время его установить ибо с прекращением поддержки 4-ки, любая найденная критическая уязвимость, может стать дыркой для хостера.
                                      По моему уж лучше Zend, да он требователен к версии PHP, но это с лихвой окупается его проработкой и гибкостью его архитектуры.
                                        0
                                        Я имею ввиду не то что для CI нельзя писать собственные модули в стиле PHP5, а то что само его «ядро» и встроенные компоненты написанные на PHP4+5

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

                                      Самое читаемое