Нужно ли разбивать на отдельные бандлы?

Question

[zenaku]

Возник вопрос по поводу определения количества бандлов в проекте на Symfony.
Имеется БД с ~15 таблицами(количество которых будет рости), которые связаны между собой "один к многим", "многие ко многим". Приложение должно будет активно работать с таблицами, постоянно запросы к БД с вытягиванием по несколько таблиц через join, изменения и так далее. Все эти таблицы переносятся в AppBundle/Entity/, где редактируются по необходимости и апгрейдят БД(при разработке, собственно,приложения ). Но держать все в одном бандле - куча конроллеров, форм, вьюшек. Хотелось бы логически разбить на бандлы - этот бандл для работы с проектами, этот бандл для работы с пользователями, это для просмотра заданий пользователям и так далее. Но все упирается в то, что необходимо тогда обращаться к сущностям в AppBundle, иначе можно насоздавать копий сущностей в разных бандлах одной таблицы(проблема с обновлением БД и повторение кода). Также проблема с гибкостью и независимостью бандлов. Но зато бандлы логически отделены, удобно отключать функциональность, обновлять через git и т.д.

В общем, как разделить на бандлы с такой структурой БД?

P.S. Возникает желание создать отдельный бандл для сущностей, к которой и прописать зависимость всех остальных бандлов

Answer 1

[Алексей Скобкин]

Create only one bundle called AppBundle for your application logic.

Из Symfony Best Practices - Creating The Project - Application Bundles.

But a bundle is meant to be something that can be reused as a stand-alone piece of software. If UserBundle cannot be used "as is" in other Symfony apps, then it shouldn't be its own bundle. Moreover, if InvoiceBundle depends on ProductBundle, then there's no advantage to having two separate bundles.

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

Хотелось бы логически разбить на бандлы - этот бандл для работы с проектами, этот бандл для работы с пользователями, это для просмотра заданий пользователям и так далее

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

Но все упирается в то, что необходимо тогда обращаться к сущностям в AppBundle, иначе можно насоздавать копий сущностей в разных бандлах одной таблицы(проблема с обновлением БД и повторение кода)

По-моему, вы тут сами не поняли, что написали. Если приведёте пример - будет понятнее.

Но зато бандлы логически отделены, удобно отключать функциональность, обновлять через git и т.д.

А вы будете отключать функциональность так часто? И что не так с git?

P.S. Возникает желание создать отдельный бандл для сущностей, к которой и прописать зависимость всех остальных бандлов

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

Comments

[zenaku]

Про разделены логически - чат, форум(тут зависимость намного меньше, но все же), работа с пользователями, работа с файлами и так далее. Это все как бы раздельно друг от друга, но все равно требует знание бандлами о пользователе, о его привилегиях(их 2 уровня - одни по типу Админ, модератор, пользователь. А второй по типу должности в проекте. То есть пользователь может еще иметь 4 должности, а админ лишь одну, а то вообще быть только админом сайта).

А вообще ваш посыл я понял. Спасибо за подробное объяснение.

Answer 2

[shagguboy]

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

Comments

[Алексей Скобкин]

Архитектура Symfony так-то тут ни при чём. Это PSR-4. Она просто тоже построена с использованием стандарта автозагрузки.