Пакеты Symfony2: я использую их правильно?

У меня есть приложение, которое разработано в Symfony2. Теперь структура для него такова:

FrontBundle - включает все, что связано с представлением приложения и пользовательским интерфейсом.
PersistanceBundle - включает все, что связано с уровнем сохранения приложения.
DomainBundle - включает все, что связано с объектами приложения и сервисами.

Является ли эта структура нормально? Или пучки используются как функция форума - ForumBundle, которая включает в себя все уровни (контроллеры, службы, логику домена и постоянство), связанные с форумом.

Ответ 1

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

Используйте один конкретный пакет приложений.. Сначала я начал с несколькими пучками, такими как CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle и т.д. В конце концов это оказалось не очень удобным, поэтому я переключился на один конкретный пакет приложений - AppBundle.

Вы можете упорядочить свой код аккуратно, используя подзоны. Например, бэкэнд-контроллеры перейдут в пространство подкатегорий AppBundle\Controller\Backend.

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

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

Ответ 2

Как сказал Эльнур, использовать один AppBundle - хорошая практика.

Один пучок реализует сам шаблон MVC, поэтому я считаю, что не рекомендуется использовать пакеты для разделения ваших слоев.

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

Связки - это кирпичи

Ответ 3

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

У меня есть два проекта со следующими структурами: оба действительны:

создание пакета для каждой функции: BlogBundle, StoreBundle и так далее, и AppBundle, который содержит общие вещи. Нет Backend/Frontend разделение. Это SaaS, где backend является интерфейсом в большинстве случаев.
Один пакет для интерфейса, один для бэкэнд. Они делят только сущности и предмет, специфичный для домена. Приложение имеет два разных конца.