PS. Палюсь… Ой как палюсь. :)

Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…

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

Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.

Проект

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

Приложения

В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.

Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).

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

Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.

Окружения (environments)

Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/не-debug имеется просто несколько различных окружений, каждое из которых можно настроить ПОЛНОСТЬЮ, т. е. не система решает — что включить, а что выключить, а вы сами. Хочется также отметить, что особо копаться в настройках вам не прийдется — по умолчанию для каждого приложения создается 3 environment’а: production, development, testing (используется исключительно при тестировании).

В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.

Модули (modules)

… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.

Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.

Последнее, на чем хотелось бы остановиться — это…

Модели (models)

Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.

Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась ему какой-то сложной и непонятной системой, какой она мне показалась год назад).

А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…

Плагины (plugins)

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

• конфигурационные файлы, в том числе свои модели (!!!)
• модули
• библиотеки

Я могу оказаться не прав, но как мне кажется, плагины — это такие себе мини-проекты, «всё в себе», чем выгодно отличаются от Symfony applications. На мой взгляд, ставку стоило делать в первую очередь на них — убрать приложения, а вместо них поставить плагины и создать некий инструмент, который бы позволил эти плагины связывать между собой.

Мои рекоммендации

• В первую очередь — проектирование. Не скупитесь на этом шаге, анализируйте и уточняйте у заказчика непонятные пункты.
• Видя перед собой (да хоть в уме) макет системы — продумайте, на какие части систему можно разбить.
• Поищите среди существующих плагинов такие части (обязательно). Я в своем проекте использовал следующие плагины:
  • sfGuardPlugin — user management, security и т.д. Плагин - must have.
  • sfDateTimePlugin — очень удобная работа с датами и временем
  • sfPropelAlternativeSchemaPlugin — полезен при работе с плагинами, позволяет менять модели, прописанные в плагинах, не изменяя коды самих плагинов
  • sfPropelApprovableBehaviorPlugin — мне очень пригодился при «активации пользователей»
  • sfThumbnailPlugin — уменьшение картинок (не смотрите на название — с ресайзом 3MP-фотографий к 800×600 плагин справляется на отлично)
  • sfPropelActAsTaggableBehaviorPlugin — если вам нужны тэги
  • sfPropelActAsSluggableBehaviorPlugin — если вам нужны slug’и (а я советую их использовать — очень хорошо сказывается на читаемости url’ов, когда вместо id туда засовывать slug’и)
  • sfPropelActAsRatableBehaviorPlugin — рейтинги, довольно крутые, мне, к сожалению, не подошли…
  • sfPropelActAsCommentableBehaviorPlugin — всё, что нужно для комментариев
• Используйте в работе автоматически генерируемые CRUD-модули и модули для админки

Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.

Давно у меня таких больших статей не было…

Запостил на Хабрахабр.

Эх… А я, видимо, до конца семестра почитать ничего нормально не смогу. :(

C# - первая версия этого языка появилась в 2000 году, для веба стал использоваться с приходом ASP.NET, который вышел в 2002м году.

Java EE -  первая версия, которая называлась J2EE и имела версию 1.2, вышла в далеком1991м году. Следующая версия 1.3 была выпущена аж через 11 лет. Сейчас новые версии выпускаются гораздо чаще. Используется в основном для разработки веб-сервисов. По крайней мере я не встречал мелкие или небольшие компании, которые писали бы “просто сайты” на Java EE.

Python - на самом деле достаточно древний язык. Первая версия языка была выпущена в 1990м году. Когда его начали достаточно сильно использовать в веб-приложениях сказать трудно. Можно считать, что в интернет он вошел с появлением таких легких и быстрых фреймворков, как Django/Turbogears и т.д. В таком случае получается что в инете он с 2004-2005-го года. На самом деле все было несколько раньше, но приход в интернет в то время был не совсем очевиден. Фреймворк Zope, который был изначально нацелен на интернет, был выпущен в 1995-1997 годах. Точнее на данный момент сказать не могу. Но еще раз повторюсь - это не было массовым явлением.

Ruby - разработан в 1995м году. В интернете стал использоваться с появлением, ясное дело, Ruby On Rails, который вышел в 2004-м году.

PHP - эдакий старичок программирования сайтов. Первая версия, которая называлась PHP/FI вышла в 1994м. А тот PHP, который мы знаем появился в 1997м году с выходом PHP3 и именно с этого момента он начал набирать популярность как язык для веб-разработки.

Perl - вышел в 1987м году, а вот когда появился в вебе - для меня остается тайной. Я этот язык особо никогда не любил и уж тем более никогда не использовал. Пользуются ли им еще в вебе - пользуются, но, как мне кажется, популярность этого языка неуклонно падает.

Теперь, собственно, к чему я вел это все. Выводы по Perl’у я делать не могу, а вот по всем остальным языкам получается интересная картина. C#/Python/Ruby - заявили массово о себе совсем недавно, причем их массовое распространение связанно с написанными для них фреймворками (ASP.NET/Django и компания/ROR). Java - в вебе используется только Java EE, и, хоть и появилась она давно, сейчас явно не собирается скидывать обороты. PHP - язычок, который пришел в веб сам, для которого до недавнего времени и фреймворков то не было, а те что были - их не использовали.

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

В итоге (все ИМХО):

1. смысла использовать PHP, если есть возможность использовать что-то более современное, - НЕТ
2. если уж использовать PHP, то с умом - не писать все сначала, а выбрать удобные компоненты для разработки нужного вам веб приложения

Из PHP Framework’ов я бы посоветовал выбрать Zend Framework, как наиболее конфигурируемый и обьектно-ориентированный. Для себя я выбрал именно его. Но в нем есть одно “но” - если вы в качестве wrapper’а для DB собираетесь использовать зендовские классы - вам возможно прийдется сменить хостера, так как нужна будет поддержка PDO/PDO_MySQL/PDO_PgSQL, которая, как мне кажется, не у всех хостеров есть.
PS. Лично мне сейчас нравится:

• для веб-разработки для себя - Python, для заказов - PHP + Zend_Framework
• для desktop-gui-приложений - C#
• для консольных - C++

PPS. Пару часов назад гуглил украинских хостеров. Завтра буду узнавать - есть ли у них поддержка PHP >= 5.1.3 и PDO_MySQL (требования к Zend Framework’у). Посмотрим, какие результаты это даст. Кто знает хороших укр. хостеров - отписывайтесь, составлю табличку - кто и что поддерживает.

PS. xen, за линк огромное спасибо!