Покрутил Symfony – PHP Framework

Опубликовал mvs3d | Дата 20.03.2009 – 22:47 |

К своему стыду, после 5-летнего опыта работы, не могу похвастать знанием какого-нибудь общеизвестного каркаса для создания приложений (Framework’а). Как-то не нужно было – использовал свои библиотеки. Однако, в последнее время часто слышу это словечко, а тут знакомый программист рассказал что на новой работе у него используется Symfony. Решил посмотреть что это за чудо такое.

Собственно мое знакомство на данный момент ограничилось чтением индесной страницы и просмотром видео-роликов размещенных на ней. Впрочем, видео там очень показательные, – сразу становится понятна суть этой системы.

Идея проста: описывается каркас приложения внутри yml-файлов, по которым система создает базу данных и генерирует PHP код. Код уже вполне рабочий, который расширяется правкой сгенерированных PHP-классов.

Кроме этого, насколько я успел заметить, среда предлагает некоторый набор функций, которые генерируют HTML тэги и JavaScript. Плохо только что это именно функции, а не методы какого-нибудь класса – а как-же ООП :) ?

Видимо из-за того, что версия фрейворка пока 1.x все файлики надо редактировать вручную, как и запускать генерацию (в командной строке). Но в будущем наверняка появится красивый инструмент для их создания “только мышкой”.

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

В общем, я для себя пока не вижу смысла в использовании подобных штук. Ведь нужно потратить колоссальное количество времени на их изучение, а потом оставаться привязанным к этой среде. А потом, если что-то работает некорректно в библиотеке? “Сливай воду” и жди апдейта?

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

  1. 30 коммент. к “Покрутил Symfony – PHP Framework”

  2. maddogg - Мар 20, 2009 | Ответить

    >>а как-же ООП
    зачем вам в шаблонах ООП?
    >>появится красивый инструмент для их создания “только мышкой”.
    нафик нафик такие вщеи. :) это уже не программирование будет, а чёрти что. Консоль only консоль, не нужнно gui для такого

    а покажите мне фреймворк где нужно писать мало? :) ну кроме django… и нет там рамок. SF на самом деле легко расширяем во многих направлениях. Нереально многих :)

    А система плагинов даёт все свои расшрирения спокойно таскать с проекта на проект – наработать придётся, но в репозитарии плагинов уже много лежит. Некоторые Фабьен и команда разрабатывает. Копайте глубже, при желании sf даёт фору в некоторым моментах другим фреймворком.

    ;) а ну да – генераторы кода можно свои писать и текущие переписывать….

  3. mvs3d - Мар 21, 2009 | Ответить

    >> зачем вам в шаблонах ООП?
    Функции, как и глобальные переменные я стараюсь не использовать в проекте без серьезной необходимости. Поэтому удивило что они тут применяются. ООП использую всегда, даже если пишу скрипт из 50 строк и 1 файла. Жалеть об этом еще не приходилось, а вот благодарить себя за эту привычку – частенько ;)
    >> Консоль only консоль, не нужнно gui для такого
    Тут мне сложно согласиться. Если есть рутина, которую можно убрать, зачем мучиться? Какой смысл в том, чтобы описывать структуру данных в текстовом файле, когда можно быстро ее нарисовать (заодно получив схему), и сгенерировать исходник?

    По поводу “рамок” – можно ту-же генерацию БД привести. Что если мне надо триггер или процедуру в базе создать? Как происходит обновление структуры данных в процессе жизни проекта? Наверное это все уже ручами делается, верно? Тогда зачем этот цирк с изобретением какого-то своего формата представления структуры?

    По поводу расширяемости читаю вот в вашем блоге “не хватает определённого набора слушателей — их мало в самом ядре, весьма”. Вы сколько времени используете это фреймворк? Почему не добавили необходимый набор слушателей :) ? Наверное что-то мешает, верно? Вот я про эти “рамки” и говорю.

    Надо присмотреться конечно к этому продукту, может быть я что-то не понимаю :)

  4. maddogg - Мар 21, 2009 | Ответить

    >>ООП использую всегда
    тут иной случай. ООП ради ООП – это всё таки черезчур :)
    Даже если скрипт 50 строк в одном файле, в последствии его и отрефакторить можно
    >>Тут мне сложно согласиться. Если есть рутина, которую можно убрать, зачем мучиться?
    во-первых, чтобы знать как себя вести в ssh – там gui нету, а через веб-интерфейс будет не всегда удобно (тем более generate:project какой-нибудь). Реверс инжиниринг вам никто не запрещает использовать – об этом Фабьен пишет. Схемы, полученные из баз данных никто не отменял (к тому они генерируются полнее некуда). Вообще сам в послее время больше прибегаю к реверс-инжиниригу, но если будет БД в 3 таблицы по 4-5 полей – быстрей описать в схеме.

    ORM (хоть Propel, хоть Doctrine) имеют совершенно иную идеологию, в отличие от обычных запросов. Хотя и raw-sql поддерживают. Триггеры возможно делать не только в БД, но в самих ОРМ (весьма полезно, и сделать можно даже больше, но медленне). Никто ничего не изобретал :) Были просто взяты 2 ОРМ. Обновление уже зависит от вас – создание дампов и пересоздание структуры есть. Если UML – тогда всё будет плясать от базы данных. Кому что удобней.

    >>По поводу расширяемости читаю вот в вашем блоге
    :) это уже не рамки, это просто не реализовано и на эту тему с Фабьеном нужно продолжать беседу. Изменить и добавить я смогу, кто бы дал только закоммитить, а плодить свои бранчи ради этих слушателей – не дело. Выход есть всегда, просто чуть тернистей, буквально на пару строк кода. Это не тривиально, на самом деле.
    А понадобится мне расширить контроллер/фильтры/логи… да много всего можно расширить, а свои расширения классов добавить всё тем же конфигом.

    >>Надо присмотреться конечно к этому продукту, может быть я что-то не понимаю
    try at least :) maybe your won’t catch an exception

  5. mvs3d - Мар 21, 2009 | Ответить

    >> ООП ради ООП – это всё таки черезчур
    Когда вы пишете код, правильно используя парадигму ООП (аккуратно описывая область видимости методов и полей – вынося общие блоки в классы-предки и т.п.), вы ведь пишете не только код но и по-сути сразу документацию на него. То что PHP позволяет использовать такие вещи как глобальные функции и переменные вовсе не означает что надо и применять – это дань совместимости с древними версиями, только и всего. Посмотрите на правильные языки, например Java – там все пишется в объектах всегда :)

    >> чтобы знать как себя вести в ssh

    А чего знать то надо в данном случае? Несколько команд (cd, cp, rm, ls)? Как редактировать в vim? Так их в любом случае надо знать, но это ведь не значит что на десктопе надо только ими и пользоваться. Хотя есть челы, которые и на десктопе не признают никаких IDE и программируют исключительно в том-же vim. Вы не из таких :) ?

    >> Схемы, полученные из баз данных никто не отменял (к тому они генерируются полнее некуда).

    Это плохой подход. Он применим как раз там где и не нужен – в базах с несколькими табличками. А когда у вас таблиц в базе скажем более 30, и не дай Бог еще не все связи между ними определены, “реверс инжиниринг” выдаст вам такую кашу, что вам она никак не поможет в понимании того как устроена база.
    Нет уж! Схема рисуется ручками, с любовью :) Таблицы группируются по разделам и внутри разделов исходя из их применения. Связи не обязательно показываются все – иначе у вас будет запутанная паутина а не схема.

    >> ORM (хоть Propel, хоть Doctrine) имеют совершенно иную идеологию, в отличие от обычных запросов.

    Угу, идеологию которая не совместима с моим подходом к разработке. Хоть убейте, я не понимаю зачем отказываться от использования SQL в угоду применения каких-то библиотек классов. Если программист пишет систему и не задумывается в том какие запросы идут к БД, или вовсе даже и не знает SQL это все – туши свет. Ведь только зная особенности работы той или иной СУБД, того как она строит план запросов и выполняет, как она хранит данные в конце-концов, только в этом случае можно написать эффективное приложение.

    Работа с базой это наиболее критичная вещь практически для любого более-менее серьезного проекта. Если вы не представляете как там все работает, это чревато серьезными проблемами тогда когда их будет сложно решать – на этапе эксплуатации.

    Триггеры в ORM это тоже нонсенс. Триггер – на то он и триггер, чтобы интегрировать логику модификации данных внутрь СУБД и расшарить ее для всех клиентов, которые к ней обращаются.

    ORM и приложения которые на них построены, хвастаются переносимостью на любую СУБД. На что я могу только одно сказать – если система работает с любой СУБД, значит она со всеми этими СУБД работает плохо! Этот “плюс” придуман маркетологами и “пипл хавает” еще.. те кто не понимает.

    Тут вспоминается один случай на Softool’е когда я остановился у стенда компании, предлагающей систему управления предприятием которая поддерживает “любую СУБД”. Ко мне подскочил скучающий менеджер и стал ее так активно расхваливать, что я решил его поставить в ступор, задав пару технических вопросов относительно реализации блока “универсальной работы с любой СУБД”. Он сразу погруснел и позвал “главного разработчика” системы, с которым мы уже нормально пообщались на этот предмет, и он подтвердил мои мысли – функционал урезан чтобы обеспечить эту самую пресловутую совместимость. Зато крупные клиенты, ведутся на гордое заявление что мол система поддерживает Oracle, хотя реально поддержка это весьма и весьма номинальна.

    >> Если UML – тогда всё будет плясать от базы данных.

    Мысль не понял :)

  6. maddogg - Мар 21, 2009 | Ответить

    >>Посмотрите на правильные языки, например Java – там все пишется в объектах всегда :)
    шаблонизатор должен быть предельно простым. PhpView таким и является. Я чес слов слабо представляю себе ООП шаблонизатор пока, хотя конечно в теории есть мысли. Но наличие ООП в хелперах тут делу не поможет. Только с толку сбивать будет. Особенно html-кодеров.
    >>Вы не из таких :) ?
    к счастью нет. Но всё таки идеология языка/фреймворка/среды проектирования весьма влияет. cli-команды sf просты, легко набираемы и проворны. Я вот например под убунтой весь софт ставлю из под консоли – быстрее и понятнее, чем через package-менеджры любые. К тому дебаг никуда не уходит, трейс всех действий в симфони можно сделать полный, а трейс через GUI – тоже слабо представляется.
    >>иначе у вас будет запутанная паутина а не схема.
    кому что :) я когда-то реверс инжиниринг тоже не понимал, теперь немного изменил свою точку зрения. Связи простраивать весьма удобно и наглядно. А из конфигов не всегда бывает запрос сложные родишь (что-что, я разбивать таблицы я умею и это даже упрощает дальнейшее расширение баз данных). А если таблиц не 30 а больше? :)
    >>Угу, идеологию которая не совместима с моим подходом к разработке.
    Любая ORM не отрицает raw-sql. Но когда нужно получить раздел и присоединённые записи к нему – куда проще и компакнтее смотрятся модели. К тому же на основе карт моделей можно строить дикие запросы и составлять нормальную гидрацию. Причём вместо составления запроса ручками даёт объектый класс, который облегчит это занятия в разы. Нередко используется практика – сначала чистый запрос, потом переводит в критерий/dql. Ничего не нарушается, добавляется множество объектности.

    >>Триггеры в ORM это тоже нонсенс.
    научите триггеры удалять файлы? Или отсылать письма? Когда идёт прямая зависимость действий от изменений БД – тут никакая СУБД не спасёт своими триггерами.

    >>тот “плюс” придуман маркетологами и “пипл хавает” еще.. те кто не понимает.
    о каких маркетологах вы речь ведёте? Что Propel, что Doctrine – это оперсорс продукты. И они не того масштаба совершенно, чтобы там такие вещи имели место. И переносимость – далеко не главный плюс. Главное – это объекность. Я себе уже слабо представляю не объекто-ориентированную работу с БД.
    А то что там продаётся – вы где у нас видел в вебе действительно качественные продукты подобные? Все CMS – фуфло сплошное. Ни одной не видел достаточно удобной и легко расширяемой. Я вообще обхожу стороной то, за что нужно платить деньги. Лучше донат скину добрым опенсорсникам – у них куда качественнее продукты. У нас все что ни делают коммерческое – делают по принципу “лижбы впарить”.

  7. mvs3d - Мар 21, 2009 | Ответить

    Мы с вами как будто в параллельных вселенных находимся – иногда вы говорите то, что прямо противоположно моим заключениям. “Шаблонизатор должен быть предельно простым.” – вот не считаю я так :) Знаком с разными подходами, темплейтными движками, но когда свободен в выборе – использую Smarty. Который не является простым, на то он и Smarty :) Почему я его так люблю? Да просто потому, что проекты, которые используют этот движок, практически единственные, где удается оставить логику представления данных там где им место – в шаблоне. Когда разработчик из-за простоты шаблонного движка вынужден вставлять в свой класс вывод кусков HTML это грустно:

    if($status==0)$this->current_row[$field]="<b>".$this->current_row[$field]."</b>";

    Против cli-команд я ничего не имею против. Просто озадачен необходимостью осваивать еще один синтаксис описания схемы БД, есть ведь – SQL :) Насчет отхода от SQL в пользу объектов приложения, я постоянно спорю об этом с коллегами, которые частенько увлекаются таким функционалом в наших проектах. Оцените вот например такой их код:

    $this->dq->join('user p', 'p.id=r.publisher_id');
    $this->dq->join('admin a', 'a.id=r.admin_id', 'left outer');
    $this->dq->order('status', false);
    $this->dq->order('upd_dts', false);

    Второй параметр метода “order” false, это что значит? Открывай код и смотри? Как передать в метод “join” тип объединения хорошо что видно только по этому тексту, а если нет? Надо документацию поднимать, и знать все эти вещи перед тем как читать такой код. А какой глубокий смысл в этом тут?

    Что понятнее “->join(’admin a’, ‘a.id=r.admin_id’, ‘left outer’)” или “left outer join admin a on a.id = r.admin_id”? Буков вроде столько же, но SQL читается значительно проще, и нужно знать только его чтобы понять что хотел написать разработчик. А со сложными, многоэтажными запросами уж тем более проще сразу читать в оригинале – в SQL т.е. Можно оправдать использование такого подхода только когда речь идет о конструировании сложного запроса в процессе исполнения “на лету”.

    >> научите триггеры удалять файлы? Или отсылать письма?

    Ну некоторые СУБД это уже давно умеют делать, хотя это конечно нонсенс. Я за штатное использование СУБД. “Триггеры” уровня бизнес-логики не должны привязываться к атомарному изменению таблиц, а должны быть частью обработки системы сигналов внутри проекта, например. Хотя для веба, какая-то надуманная сложность. Если привести пример, скажем нужно удалить юзера из базы, связанный с ним файл (аватарку) и послать ему мыло оповещение, мол тебя удалили. То да, делается класс “user” с методом “delete” который и выполняет всю эту логику (при этом внутри метода delete я вижу чистый SQL). А вот если надо удалить связанные записи из базы по этому юзеру, то такой фукционал надежнее поместить внутрь базы данных – база должна сама уметь обеспечивать свою целостность.

    Насчет CMS согласен. А знаете почему они “все фуфло”? Потому что нельзя написать универсальный продукт, который одинаково хорошо выполняет любые задачи. Наиболее часто встречающая ошибка программиста – это когда он решает взять свой класс, и сделать его универсальным – для всех случаев. Результатом этого обычно является куча потерянного времени и нечто монстроидальное (гыгы, проверка орфографии предложила заменить это слово на “геморроидальное”.. – прям в точку) на выходе. Я пришел сейчас к такому подходу – если решаю задачу которую раньше делал, беру исходник и при необходимости ни сколько не сомневаясь кромсаю его по месту. Получается быстро, практично и красиво (не надо тянуть за собой хвост совместимости, опыт растет – код упрощается). А оставаться заложником обеспечения совместимости, когда при разработке нового продукта половина усилий сводится на ее обеспечение, этим можно баловаться при больших бюджетах или из любви к искусству :)

  8. maddogg - Мар 21, 2009 | Ответить

    >>Когда разработчик из-за простоты шаблонного движка вынужден вставлять в свой класс вывод кусков HTML это грустно
    Под простотой имелось ввиду нечто иное :)
    Smarty – это конечно хороший шаблонизатор – работал, знаю. Даже в то время когда в нём с ООП было плохо – отделять View помогал. Но сейчас стараюсь обходить стороной такие шаблонизаторы. Куда проще и наглядней передать шаблону объект модели и там уже работать с ним (но на уровне вывода! не более). В итоге не приходится никакие переменные передавать дополнтельные.
    Может у меня просто предвзятое отношение – раньше был какой-то кривенький шаблонизатор, который просто хреново воспринимал массивы и вообще не умел работать даже с простыми for/foreach. И это меня как-то бесило. В итоге склоняюсь теперь больше к шаблонизаторам с нативным PHP.
    Смысл таких шаблонизаторов я вижу ещё в том же django – но это совсем иной случай, питон он на то и питон.

    Насчёт ORM переубеждать не буду :) Тут на самом деле кому что удобнее. Панацеи нет, есть только аспирин и алказельцер :)

    Насчёт триггеров: ondelete cascade, onupdate cascade – ещё да, отлично. Целостность базы данных, уж извините, но на голове разработчика. База данных ничего кроме хранения и выдачи по идее то не должна разработчику. Ну это моё сугубо-личное мнение.

    CMS бы могли быть как минимум более расширяемы – огромный набор интерфейсов в зубы девелоперу, абстрактных классов тоже. И стандартные действия – список, айтем, редактирование, удаление. И чтобы где захотел – там создал экстенд без проблем. А то что делается – делается монолитным, без намёка на проектирование даже. Я уж не буду говорить про ляпы, которые можно в коде увидеть.

  9. maddogg - Мар 21, 2009 | Ответить

    :) да уж. Сразу видно различия между XP и UML девелоперами

  10. mvs3d - Мар 21, 2009 | Ответить

    >> Целостность базы данных, уж извините, но на голове разработчика.

    Ну да, конечно! А foreign key придумали так, чтобы реверс-инжиниринг скрипты работали для тех кто документацию на БД в процессе разработки не пишет :) ?
    Задача СУБД обеспечить хранение и целостность данных. Задача разработчика внести логику сохранения целостности в СУБД иначе грош цена такой БД или такому разработчику, у которого все “в голове” ;)

    >> Сразу видно различия между XP и UML девелоперами

    О как :) Даже задумался, и кто из нас кто, по-вашему?

    UML это всего-лишь язык с помощью которого можно рисовать схемы, которые были бы понятны другим. Почему вы его противопоставляете XP мне не понятно. Наверное возникают ассоциации с RUP? Я бы себя скорее причислил к сторонникам гибких методологий – итеративный подход, частые релизы, парное программирование, рефакторинг – наше все :)

  11. Кирилл - Апр 13, 2009 | Ответить

    >> CMS бы могли быть как минимум более расширяемы – огромный набор интерфейсов в зубы девелоперу, абстрактных классов тоже. И стандартные действия – список, айтем, редактирование, удаление. И чтобы где захотел – там создал экстенд без проблем.

    CMF? :)
    Хочу поделиться. Смотрите в сторону yiiframework.com – может больше понравится.

    Насчет
    >> $this->dq->join(’user p’, ‘p.id=r.publisher_id’);
    если Ваши коллеги пользуются наждаком, вместо туалетной бумаги, это еще не значит, что на прилавках только наждачная бумага.
    Я сам до недавнего времени убежденный native-php developer, но с недавнего времени осваиваю Yii – очень нравится. Очень грамотно всё сделано.

  12. mvs3d - Апр 13, 2009 | Ответить

    Насчет туалетной бумаги мысль не понял :)

    Yii посмотрю, спасибо! Кстати, как оно произносится по-русски :) ) ?

  13. Кирилл - Апр 13, 2009 | Ответить

    >> Yii посмотрю, спасибо! Кстати, как оно произносится по-русски :) ) ?

    Я называю “Юи” :) Хотя сами авторы дают транскрипцию [i:] (длинное “иии”). Первый вопрос насчет фреймверка, к стати, – “как его называть по-русски?”.
    На Хабре даже было что то вроде холивара на эту тему.

    Насчет бумаги и наждака суть проста – они пользуются некачественными разработками, используя которые можно только геморрой нажить, качественным продуктом пользоваться приятно :) Может быть сравнение и нелепое или даже неуместное – хотелось просто немного юмора добавить.
    Тот же самый пример с JOIN’ом, в Yii используя CActiveRecord класс в отношениях можно указать ‘joinType’=>’INNER JOIN’ или ‘LEFT OUTER JOIN’, например.
    Хотя там есть довольно таки удобный DAO (Data Access Objects) API инструменарий – надстройка над PDO (PHP Data Objects).

  14. mvs3d - Апр 13, 2009 | Ответить

    Да, странное название.. почти как Wii :) )

    Насчет JOIN в классе, они пользуются тем что сами написали, и меня склоняют к этому постоянно :) Но я сопротивляюсь этому потому что лично мне удобно видеть текст SQL запроса целиком – лучше читается и понимается что он там делает.

    А когда это делается через класс, то во-первых некоторые части запроса могут быть определены, скажем, в предке (т.е. сразу всю конструкцию целиком можно и не увидеть), во-вторых при чтении приходится фильтровать эти PHP-шные вызовы. Ну а в третьих, запросы бывают нетолько с JOIN а всякие сложные конструкции с вложениями которые в нашем “фреймворке” не предусмотрены, ну а если где-то еще предусмотрены то могу себе представить какие там сложные конструкции получаются… И все это ради чего? Чтобы программист на PHP мог не знать SQL?

  15. Кирилл - Апр 13, 2009 | Ответить

    >> И все это ради чего? Чтобы программист на PHP мог не знать SQL?

    Конечно :)

    >> Кроме этого, насколько я успел заметить, среда предлагает некоторый набор функций, которые генерируют HTML тэги и JavaScript. Плохо только что это именно функции, а не методы какого-нибудь класса – а как-же ООП ?

    Yii – 100% ООП ;)

    >> Насчет JOIN в классе, они пользуются тем что сами написали, и меня склоняют к этому постоянно

    С кем поведешься – так тебе и надо :)

    Я наверное уже чуть ли не как рекламу толкаю этот Юи :) ) На самом деле просто нашел Ваш блог в гугле, почитал и понял, что мы с Вами очень похожи в идейном плане программирования. Самый первый пост я бы мог 1 в один написать точно так же :) Поэтому и подумал, что он и Вам может показаться интересным.

    К стати…
    >> >> Но в будущем наверняка появится красивый инструмент для их создания “только мышкой”.
    >> нафик нафик такие вщеи. это уже не программирование будет, а чёрти что. Консоль only консоль, не нужнно gui для такого

    ASP-шники давно пользуются сиими благами. Единственный глюк – клоунов разведется уйма, предлагающих сделать сайт за 500р (мне, как фрилансеру, это неприятно как минимум)… И недо-программистов. Хотя, как показывают некоторые случаи, всё в конечном итоге даже на руку получается – уже не один раз обращались люди, которым что-то на сайте криво сделали и нужно переделать :)

  16. mvs3d - Апр 13, 2009 | Ответить

    > Поэтому и подумал, что он и Вам может показаться интересным.

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

    Впрочем, изобретать велосипед тоже не хочется, да и сложно при этом конкурировать с “500рублевыми” сайтами :) Поэтому я и присматриваться стал к этой теме.

  17. Кирилл - Апр 17, 2009 | Ответить

    >> Впрочем, изобретать велосипед тоже не хочется, да и сложно при этом конкурировать с “500рублевыми” сайтами :) Поэтому я и присматриваться стал к этой теме.

    А я вот как раз хотел было изобрести велосипед. Дело в том, что сейчас понадобилось не просто иметь свои библиотеки с функциями/классами, а полноценный фреймверк. Написал я значит себе планчик того, что этот фреймверк должен уметь и планировал, что этот фреймверк будет использовать моя организация (я планирую создать свою веб-студию, поэтому “моя организация” пока что слишком сильно сказано). Я, как и Вы (насколько я понял) люблю управлять процессом создания сайта, а для того, чтобы им управлять, нужно иметь представление обо всех его компонентах и их реализации, соответственно, чтобы не только контролировать чью-то работу, но и ускорить ее (посредством заранее готовой функциональности и использования предопределенной бизнесс-логики – по сути то, что во фреймверках осуществляют контроллеры). К тому же фреймверк определяет структуру директорий сайта, в проектах, созданных год или 2 назад можно будет копаться очень долго в поисках “куда же я засунул файл конфигурации”… даже несмотря на то, что я обычно использую одну и ту же структуру – жабаСкрипт у меня в /js/, css – в /css/, файлы, которые определяют работу с формами в /exec/ и т.д. – это уже “отточенная” система хранения используемых сайтом директорий. В общем, это только самые очевидные причины использования полноценного фреймверка. Нынешние фреймверки не понравились особо – тяжеловаты да и не все поддерживают php5, а те, что поддерживают – не нравятся даже с первого взгляда. Я уже готов был писать всё самостоятельно с нуля (чисто под мои задачи, а не 3Мб голого кода – свихнуться можно), но тут подвернулся Юи.
    Можете еще холивар про использование/не использование фреймверков почитать на Хабрахабре – занятное чтиво, хотя и пустое, т.к. в конечном счете каждый сам для себя определяет.

    Про 500рублевые сайты… Только что видел объявление в 5 раз длинней чем этот мой пост, в котором очень предприимчивый школьник пытается предоставить услуги по созданию сайта… на юкозе :) ) Мне бы стыдно было предлагать даже такое, а там еще и в таком промо-стиле всё описано… любо-дорого читать :)

  18. mvs3d - Апр 17, 2009 | Ответить

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

    Что касается “забыл через 2 года что где находится”, проблема известная :) Но тут дело ведь не в том, что либу какую-то используешь. А скорее в том, что каждая новая разработка по чуть-чуть ее изменяет, как нам кажется в лучшую сторону, и глядишь, через 2 года получается совсем все по-другому. И с фреймворками наверяка так-же все будет.

    У меня сейчас получилось так, что есть очень много наработок, но код там был написан очень давно. А это значит, что еще тянутся хвосты совместимости с PHP4. Обработка ошибок была построена не на исключениях, что так-же бьет по красоте и эффективности кода. Встает вопрос, либо все это переписывать, либо присмотреться к тому что есть готовое. На самом деле, любой подход имеет право на жизнь… хватило бы здоровья на все, и таланта на то чтобы спроектировать красивый каркас :)

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

    Кстати, а вы Symfony то смотрели? Как он вам, самому?

  19. Кирилл - Апр 17, 2009 | Ответить

    >> Кстати, а вы Symfony то смотрели? Как он вам, самому?

    Вот, к стати, Симфонию не смотрел. Я при выборе фреймверка зашел в гугл дабы найти какой-нибудь обзор фреймверков и Симфония (так ей и надо) была в самом хвосте весьма внушительного списка фреймверков (ну, начинается она плохо – на “S” :) ), поэтому начав с Akellos (насчет названия не уверен, но по-моему именно Akellos или Akkello или еще как-то :) ) так и не добравлся до Симфонии. Yii вообще не было в списке, к стати, но буквально на следующий день я на него наткнулся на Хабре и мне хватило сравнения фреймверков (http://www.yiiframework.com/performance/) по результатам которого Симфония оказалась не только в конце списка благодаря своему названию, но и благодаря своим “скоростным” качествам, поэтому смотреть так и не стал. К стати, скоростные качества Yii очевидны – использование lazy loading решает! :) )
    К стати… еще один небольшой “хинт” – используйте NetBeans IDE от компании Sun в качестве редактора (до использования Yii я пользовался PHP ExpertEditor 4.2 – у меня даже лицензионная версия, которую я честно купил примерно за 30$ :) ). Дело в том, что НетБинс кроме того, что подсказывает какие методы есть у экземпляра класса, так еще и дает справку по каждому методу/свойству, а также где он был декларирован, – это очень удобно… Вспоминается Borland C++ :) Что мне нравится в ЭкспертЭдиторе – подсвечивает параметры библиотечных функций – жаль, что этого нет в НетБинс :( хотя может быть и существуют какие-то расширения для него – не знаю – не “копал”.
    Еще на сайте Юи появился видео-туториал “как сделать блог на Yii за 30 минут” и хотя автор там действует методом копи-паста уже готовой функциональности, даже если писать код самостоятельно, свой блог вполне реально написать за день. У меня сейчас есть один заказ + свой сайт нужно сделать – буду делать на Yii – отпишусь насколько реально разрабатывать при помощи него реальные сайты.

  20. mvs3d - Апр 17, 2009 | Ответить

    Понятно, хотя сравнение скоростных качеств вызывает некоторое сомнение в объективности (в смысле непонятно, а что именно тестировалось то собственно), но список фич Yii вызывает уважение. Буду разбираться с ним в первую очередь.

    По поводу NetBeans IDE. Я ее как раз недавно пробовал, в блоге не успел отписаться. Пробовал достаточно плотно – работал около 2-х недель, но все-таки отказался от нее в пользу ранее используемой мной Eclipse. В NetBeans мне понравилась стабильная скорость работы (один раз подождал пока все прогрузится и потом пашет, в Eclipse бывает в процессе призадумывается), понравилось интеграция PHPDoc – в смысле всплывающих хинтов, и то что заготовки комментария вставляются сразу нужные, стоит написать прототип метода и ввести начало коммента (”/**”+ENTER). Однако некоторые досадные моменты были (code folding настроить нельзя – либо все схлопывается, либо развернуто.. да и тормозит.. я как то средненький html открыл, и все.. труба – ждемс.. потом закрыл, и надо было опять его глянуть – снова ждать пока прогрузится, а потом разворачивать уровни в code folding). Ну а последней каплей был глюк с SVN, которая находится на сервере с неправильным сертификатом (https) – жму “доверять ресурсу”, а он снова и снова выдает предупреждение.

    Ну в общем, я решил что “старый глюк лучше новых двух” и вернулся на Eclipse 3.4 + PHPEclipse. Эту связку я уже 5 лет использую, и доволен. Есть там и навигация по классам, и всплывающие подсказки как твоих классов, так и встроенных функций PHP. Ну и еще много чего есть вкусного, чего я не заметил в NetBeans 6.5.

    >> буду делать на Yii – отпишусь насколько реально разрабатывать при помощи него реальные сайты.

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

  21. relo_san - Окт 12, 2009 | Ответить

    >> И все это ради чего? Чтобы программист на PHP мог не знать SQL?

    Да вы простите, просто бредите. Я хочу посмотреть, что серьезное вы нарисуете в ORM, не зная SQL. ORM нужен совсем для другого – для гибкости разработки, поддержки и рефакторинга, а также для уменьшения тривиальных ошибок и объема ненужного кода.
    Представьте себе приложение, имеющее в паре тысяч файлов порядка 500 SQL запросов. Вам нужно немного изменить структуру базы. Ваши действия?
    Без ORM вы сначала смените структуру, потом либо прогуляетесь по всем файлам и просмотрите все запросы на предмет их адекватности в связи с изменением, либо запустите приложение и при тестировании начнете отлавливать возникшие баги, искать где они возникли и делать правки в соответствующих запросах. С ORM вы просто меняете конфиг и перегенериваете классы. Равноценные по объему работы?
    А теперь представьте, что вам понадобилось такой проект перевести с одной БД на другую, скажем с MySQL на PostgreSQL. Сколько запросов в скольких файлах вам предстоит поменять?
    Удачи вам в работе с голым SQL :)
    И вообще, большая часть высказанных суждений – ну очень обывательские. Вроде как вы всю жизнь просидели на Joomla, а потом глянули на Symfony и ужаснулись :)

  22. mvs3d - Окт 12, 2009 | Ответить

    Кто бредит? Точно я :) ?

    Приведите пример изменения структуры БД, после которого требуется проверка всех запросов на предмет валидности. И пример кода в ORM, который не нужно изменять при таком изменении.

    Последнюю ремарку вообще не понял, как можно сравнивать Joomla и Symfony (первое CMS, второе фреймворк). Все равно что сказать, что “всю жизнь сидели MS Word, а потом открыли PHP код и ужаснулись” :)

  23. relo_san - Окт 12, 2009 | Ответить

    Вы знаете, холивары вообще, и на тему ORM vs notORM меня как-то мало интересуют, и тратить на них время мне неинтересно.
    Вы реально помните где какие из 500 запросов в вашем приложении что делают, чтобы однозначно определить, какие менять а какие нет? А если это не _ваше_ приложение и вам нужно его рефакторить? А если вы над приложением работаете не один, а группой в 5 человек и там не 500 запросов а 5000? Вы серьезно можете гарантировать заказчику надежность работы и отсутствие багов в приложении после изменения структуры, не проверив все запросы, а ограничившись только теми, что _по вашему мнению_ затрагивает сделанное изменение? Ну опять таки, удачной разработки :)
    В ORM, если вы умеете им пользоваться – таки да ничего изменять не надо, кроме модельки. Ну может пару методов в класс модели добавить или поправить существующие и классы форм поправить, если требуется. Итого: 3-4 файла. Все. Все ваше приложение вне зависимости от его величины – уже работает с новой структурой базы. Если приложение конечно не идиот писал и структура у него грамотная.
    Можете не отвечать, дальше мне неинтересно :)

  24. mvs3d - Окт 12, 2009 | Ответить

    Мне как раз очень интересно. Извините, но это все просто слова, весьма избитые причем.

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

    А холивары, ну их. Давайте по делу.

  25. relo_san - Окт 12, 2009 | Ответить

    Ну предположим у вас есть приложение, в нем есть некая гео-структура, аля Страна -> Регион -> Район -> Город. Это упрощенная нереальная модель, но не суть важно. Объекта “Улица” у вас пока нет, сама по себе улица забита прямо в поле объекта (например юзера). Вам нужно ее добавить. Это соответственно еще одна таблица со связями.

    Без ORM: Вы добавляете табличку и начинаете серфить по вашему или не вашему коду, чтобы определить, где находятся те 20 мест в проекте, где выбирается из базы и формируется адрес какого-либо объекта, чтобы поменять там вызовы и формирование строки адреса. Вы ведь правда не думаете, что в угоду удобства рефакторинга вы будете делать запрос адреса в одном месте, насрав на производительность и увеличив количество запросов к базе? Потому что тогда нужно будет отделить не только адрес, но и еще десяток параметров, и в итоге вы получите не 10 запросов в БД на страницу, а 120, что врядли порадует вашего заказчика. Также не рекомендую приводить в пример методы размазанных запросов (аля Joomla, где начало запроса может быть в одном файле, а окончание – в 25-м). Ну так вот – вы бродите по коду и ищете те места, где для 20 различных объектов (адреса пользователей, фирм, домов и прочее) выбираются их адреса, и планомерно все там меняете. Затем вы проделываете магические пассы в админке, формах юзерки, чтобы там появились нужные селекты и прочая муть, переписываете сохранение всей этой новой структуры. Великолепная работа, минимум неделя времени оплачена из кармана Заказчика.

    P.P.S. Глючит ваш блог, видимо много букав не переваривает, пришлось разделить на 2 комментария…

  26. relo_san - Окт 12, 2009 | Ответить

    Продолжение банкета…
    С ORM: Вы меняете модельку вашего плагина, отвечающего за все работы с структурой Страна -> Регион -> Район -> Город, добавляете в него объект “Улица”. Меняете _один_ метод выборки и формирования адреса, теперь уже универсальный для всех объектов, ибо количество запросов не возрастет и можно (нужно!) разместить его в _одном_ месте. И меняете пару формочек, поправив в их конфигах соответствующие селекты (в основном для красоты, ибо сгенеренная форма уже и так будет иметь нужный селект).
    Делается это все добро за час, с добавлением всяких красивых примочек типа автодополнения – за 2-3 часа.

    И это, трудитесь самостоятельно. Кто хочет – тот сам роет, изучает и понимает необходимость или отсутствие оной в использовании чего-либо.
    Имхо, глупо писать подобные раассказы, не поимев хотя бы полгода опыта в той технологии, о которой пишешь. Ничего полезного все равно не напишется, разве что для сбивания с толку себе подобных.

    P.S. ORM – не панацея, но _очень_ удобное средство для разработки средних, больших и реально больших проектов, в особенности большой группой программистов. Экономит 500% рабочего времени.

  27. mvs3d - Окт 12, 2009 | Ответить

    Так, сегодня я не форме, перепутал ООП с ORM, позже отвечу :)

  28. relo_san - Окт 12, 2009 | Ответить

    1. Симфония никого ничего не зааставляет делать. И сам фреймворк, и ОРМ в нем – предоставляют очень гибкую структуру, из которой можно слепить что вам угодно, в зависимости от конкретной задачи.

    2. Для сайтов-визиток и прочих проектов типа “неделька” – ни Симфония, ни ОРМ – не нужны. Это все равно что делать индикатор напряжения сети на базе процессора Пентиум. Просто у нас разные понятия о средних проектах. Для меня средний проект – это где-то от 100 таблиц со связями и несколько месяцев серьезной работы.
    На счет интернет-магазина – сколько нибудь серьезный интернет-магазин – содержит минимум под сотню таблиц, что никак не назовешь маленьким проектом. Я говорю не о поделках, а о серьезных магазинах с серьезным функционалом (ничего нормального на PHP в публичном доступе на эту тему к сожалению нету, хотя по напичканности функционалом можно выделить например Magento, главное при этом – не смотреть в его внутренности). И вот там, исходя из объема и количества связей, работа с SQL напрямую радости точно уже не принесет.

    3. Оно конечно понятно, что вам удобно написать такой пост и ждать, пока кто-то распишет и разложит вам все по полочкам. Вот только комментов таких по интернету – не один и не два, а тысячи. И совершенно логично, что мало кому интересно отписываться. Зато человек, который информацией не владеет – прочитает десяток таких блогов и поймет – “херня этот ОРМ, дебилы для дебилов его придумали и вообще он нафиг не надо”. Так и создается “общественное мнение”.

  29. Alexander - Май 4, 2010 | Ответить

    Прошёл шаги в примерах Symfony. Проект заработал – но добиться этого было не так просто. Во первых действуя строго, как мы говорим, по инстукции – тут и там результаты шокирующе отличались от сказочного текста, пришлось изучать, отлаживать, анализировать код, чтобы убрать всплывающие ошибки.
    Даже прошлось начать всё заново несколько раз. Как откатить назад если что то не так сделал – вопрос. В целом для работы требуется изучение основных идей и концепций, и непосредственно кода ядра Symfony. Необходим опыт – сын ошибок, возможно и гений, работы с его компонентами. Мы говорим – всё гениальное просто. Я затрудняюсь сказать это про Symfony.

  30. Serjo - Ноя 16, 2010 | Ответить

    Если Вы никогда не использовали фреймворков, тогда понятно почему Вы так бьетесь за свою независимость)))

    Автор статьи не прав!!! Смарти тот же в шаблонах ООП не исмпользует (хотя и можна). Самые авторы Смарти рекоендуют минимально програмировать в шаблонах. К вашему сведению Смарти прост))) На то он и Смарти. Вы его не потрудились посмотреть и утверждаете свою идеологию))

    Вопрос сколько времени Вам нужно чтобы сделать модуль коментарии для любой таболицы???
    Вместе с schema.yml + Doctrine мне нужно 10 мин :)

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

    Все базовое что нужно, есть в Symfony, для бистрой разработки.

    ООП – это не закон. ООП – это даже не правило. Это метод! И его нужно применять тогда когда нужно, зачем стрелять по воробъям из пушки, если достаточно ружья.

    Не судите, первое мнение обманчиво и второе и 5 следующих тоже.

    Удачи Вам.

  31. mvs3d - Ноя 16, 2010 | Ответить

    Значит так, время идет – все меняется. И мнение тоже может поменяться :) Собственно относительно Symfony оно осталось прежним, но за это время я познакомился с Zend Framework. Вот это действительно то что нужно!

    Поясню в чем отличие. Дело в том, что Zend предлагает каркас для разработчика, готовых “модулей комментарии для любой таблицы” там нет, но есть скелет по которому предлагается строить ваши приложения. И скелет этот очень хорошо продуман!

    Что касается быстрого создания базовых вещей, для этого существуют наработки программистов. У каждого они есть. У меня они тоже есть для “чистого PHP”, и создание шаблонных вещей у меня и раньше занимало пресловутые “10 минут”.

    Зачем же тогда нужен Zend, просите вы? А очень просто – я считаю что базовые вещи можно использовать сторонние (прекрасный пример – работа с базой данных, ООП враперы для манипулирования данными). Кроме этого, Zend направляет разработчиков в одно русло – начиная от правил оформления кода, именования объектов и заканчивая обработкой данных их HTML форм.

    Так что Zend – это наше все :) Новый проект делаем на нем.

    Symfony и иже с ними находится чуток выше по уровню абстракции, и для меня неприемлем – слишком много там готового кода на мой взгляд ;)

    PS Насчет Smarty (Smarty значит “умный”, в переводе). И он действительно такой, – в шаблоне можно программировать. В простых движках этого нет.

Оставить комментарий или два

Об авторе

Меня зовут Владимир. Я живу в России, в г.Тольятти Самарской области. C 2004 года активно занимаюсь Web-разработками. Интересуюсь развитием сервисов Сети, технологиями создания и продвижения Интернет-ресурсов, компьютерными железками.. и не только ;)

Подпишись на обновления!

 RSS-канал / Email-рассылка
Поиск :