Как разделить приложение на Symfony2 на backend и frontend?

Потихоньку перехожу с Yii1 на Symfony2.
В Yii приложение можно было разделить на back- и frontend двумя способами: разделение на два приложения (папки common, frontend и backend) со своими точками входа (frontend/web/index.php и backend/web/index.php) и добавление модуля Backend.

Меня интересуют три вопроса:
1) Какие есть способы в Symfony2?
2) Как правильно использовать бандлы? Допустим, я делаю интернет магазин со обычным функционалом (пользователи с регистрацией, товары, заказы и т.д. + админка). Какие тогда будут бандлы?
3) Что это еще за папка Acme в src? Вернее, я знаю, что такое Acme Corporation и Acme вымышленно название для примера, но почему все бандлы лежат в этой папке? Как она должна называться в реальном проекте?
  • Вопрос задан
  • 5064 просмотра
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
1) все те же. Разделение приложения на два отдельных (можно сделать через одну точку входа и использовать мидлвар URL-map что бы разруливать разные приложения по урлам. Можно разделить на бандлы - FrontendBundle/BackendBundle. Этот вариант чуть менее гибок, так же как и в случае с модулями в Yii. Хотя жить можно. Лично я пробовал вариант с полным разделением лишь один раз, ибо логика бэкэнда и фронтэнда и настройки приложений слишком уж различались. Да и изначально разработчики Symfony планировали что люди будут так делать, но подход с бандлами стал популярнее.

Разве что могу сказать, что выносить общие настройки приложений, общие части и т.д. с Symfony чуть проще.

2) Бандлы должны быть самодостаточны. По сути это модули. Если вы не планируете реюзать код в других проектах, то смысла выносить этот код в отдельный бандл нету. В 99% случаев смысла разности бизнес-логику приложения по разным бандлам нет.

Обычно делают какой-то CoreBundle/SiteBundle/AppBundle или что-то в этом духе и там делают всю логику проекта. Если появляется какой-то функционал, который можно реюзать (например слой абстракции для работы с платежными системами, система уведомлений или чего еще), это дело можно вынести в отдельный бандл и в последствии реюзать.

Так же довольно распространенная практика хранить код просто в неймспейсе проекта, а в бандлах хранить только вещи специфичные для Symfony (регистрация сервисов, настройки валидаторов, мэппинг базы и т.д., то есть все то что нужно именно Symfony). Подобная структура проекта частенько мелькает когда рассказывают о DDD, да и на самом деле таким образом проще держать проект в чистоте. Если у вас еще и контроллеры как сервисы определены, то вообще красиво выходит. Но это все для ослабления связи кода вашего проекта и фреймворка.

3) Это неймспейс. Обычно вместо Acme пишут либо название проекта либо имя фирмы исполнителя/никнейм фрилансера...

Большинство людей смущает необходимость хранить код на один уровень ниже. Скажем у вас только один неймспейс, код весь в нем, какой смысл в папке src хранить одну единственную папку? Вот и придумали стандарт PSR-4, который позвляет указать префикс. Например что бы избавиться от папки Acme, все его содержимое можно перетащить на уровень выше (прямо в src), и в composer.json прописать
"autoload": {
    "psr-4": {"Acme\\": "src/"}
}

Это все чисто вопрос нэймспейсов и настройки автозагрузки.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
WarGot
@WarGot
/src/Project/Controller/
/src/Project/Controller/Api/*Controller.php
/src/Project/Controller/Backend/*Controller.php
/src/Project/Controller/Frontend/*Controller.php

У нас примерно так реализовано разделение проекта, бандл один. Всё кроме контроллеров лежит в своих директориях без разделения.
Дизайн в app/Resource/view также с разделением на BackEnd, FrontEnd. В корне view общие вещи, макросы, формы, базовый слой.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы