Чем больше я работаю над своим первым проектом на работе, тем больше мне хочется в нем поменять и тем больше я жалею о том, что перед началом работы я не прочитал до конца «The Definitive Guide to Symfony» и не изучил плагины для Symfony. Многие из них мне бы помогли намного сократить время разработки и, что самое главное, не думать о том, как красиво реализовать те или иные вещи… И еще одно — если у вас уже есть кусок системы (как это было у меня), который вы собираетесь переписывать с использованием вашего фреймворка (или просто переписывать, потому что код вам не нравиться) — то мой вам совет — потратьте время на то, чтобы спроектировать этот кусок на план вашей новой системы, не бросайтесь сразу всё переписывать (каюсь, я поступил именно так), так как после анализа (который, возможно, займет у вас не один день, и даже не одну неделю), возможно, от предыдущей архитектуры системы не останется и следа.
Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…
Ну ладно, это я отвлекся. Сегодня хочется рассказать о том, с чего стоит начать при разработке системы с помощью Symfony и каких правил следует придерживаться.
Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.
Насколько я понял, в общем случае предполагается, что проект у вас будет один на весь сайт, и он будет представлять собой некое хранилище приложений, конфигурационных файлов и моделей, которыми будут пользоваться все приложения этого проекта.
В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.
Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).
Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.
Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.
Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/не-debug имеется просто несколько различных окружений, каждое из которых можно настроить ПОЛНОСТЬЮ, т. е. не система решает — что включить, а что выключить, а вы сами. Хочется также отметить, что особо копаться в настройках вам не прийдется — по умолчанию для каждого приложения создается 3 environment’а: production, development, testing (используется исключительно при тестировании).
В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.
… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.
Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.
Последнее, на чем хотелось бы остановиться — это…
Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.
Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась емукакой-то сложной и непонятной системой, какой она мне показалась год назад).
А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…
Плагины — это, по сути, тот код, который может быть использован несколько раз в разных проектах и приложениях. Плагины могут содержать:
Я могу оказаться не прав, но как мне кажется, плагины — это такие себе мини-проекты, «всё в себе», чем выгодно отличаются от Symfony applications. На мой взгляд, ставку стоило делать в первую очередь на них — убрать приложения, а вместо них поставить плагины и создать некий инструмент, который бы позволил эти плагины связывать между собой.
Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.
Кросспост на моем блоге.
Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…
Ну ладно, это я отвлекся. Сегодня хочется рассказать о том, с чего стоит начать при разработке системы с помощью Symfony и каких правил следует придерживаться.
Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.
Проект
Насколько я понял, в общем случае предполагается, что проект у вас будет один на весь сайт, и он будет представлять собой некое хранилище приложений, конфигурационных файлов и моделей, которыми будут пользоваться все приложения этого проекта.
Приложения
В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.
Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).
Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.
Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.
Окружения (environments)
Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/
В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.
Модули (modules)
… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.
Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.
Последнее, на чем хотелось бы остановиться — это…
Модели (models)
Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за
Пожалуй, это всё, что может понадобиться новичку при изучении 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-модули и модули для админки
Ссылки по теме
- Отличная серия постов по Symfony 1.1 Form Framework
- Блог по Symfony
- Русскоязычное сообщество Symfony (на мой взгляд, если у вас с английским более-менее нормально, сюда лучше вообще не ходить).
- Книгу по Symfony на русском лучше всего читать здесь (есть несколько переводов, как я понял, один из них на вышеприведенном сайте, но тут — самый полный).
Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.
Кросспост на моем блоге.
