В Symfony Best Practices рекомендуется не использовать пакеты для организации бизнес-логики.
Связки должны использоваться только тогда, когда код в них предназначен для повторного использования как есть в других приложениях:
Но пучок должен быть чем-то, что можно использовать повторно автономной части программного обеспечения. Если UserBundle нельзя использовать "как есть" в другие приложения Symfony, то это не должно быть его собственным пакетом.
Итак, когда я обновляю свое приложение от Symfony 3.3 до Symfony 4, я думаю, что сейчас самое подходящее время для реорганизации моего кода.
В настоящий момент я следил за "связкой-структурой":
- src
- AppBundle
- Controller
- Entity
- Repository
- Resources
- ...
- MyNamespace
- Bundle
- BundleTodo
- Controller
- Entity
- Repository
- Resources
- ...
- BundleCatalog
- Controller
- Entity
- Repository
- Resources
- ...
- BundleCart
- Controller
- Entity
- Repository
- Resources
- ...
- ...
Теперь, с новой структурой каталогов, как мне организовать код?
Я хотел бы организовать его так:
-src
- Core
- Controller
- Entity
- Repository
- ..
- Todos
- Controller
- Entity
- Repository
- ..
- Catalog
- Controller
- Entity
- Repository
- ..
- Cart
- Controller
- Entity
- Repository
- ...
Но, это правильно? Есть ли проблемы с ожидаемой структурой папок Symfony 4 и Flex?
Или лучше что-то вроде этого:
-src
- Controller
- Core
- Todos
- Catalog
- Cart
- ...
- Entity
- Core
- Todos
- Catalog
- Cart
- ...
- Repository
- Core
- Todos
- Catalog
- Cart
- ...
- ...
То же самое относится и к другим корневым папкам, как описано в структуре каталога проекта (о том, как переопределить его).
Существуют ли какие-либо правила или ограничения, которые я должен учитывать при выборе моей новой структуры папок?
ПЫТАЯ РЕШИТЬ ПРОБЛЕМУ
Итак, пытаясь решить проблему, я пойду глубже в документации, и я напишу здесь, что я найду.
- Контроллеры: используйте мелкозернистую конфигурацию контроллеров.
- Twig:
- Сущность: используйте
orm.entity_managers.some_em.mappings.mapping_name