建议Symfony Best Practices不要使用bundle来组织业务逻辑。
仅当其中的代码要在其他应用程序中按原样重用时,才应使用它们:
但是捆绑包意味着可以作为一个重用的东西 独立的软件。如果不能使用UserBundle"按原样#34;在 其他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
- ...
- ...
同样适用于project directory structure中描述的其他根文件夹(关于如何覆盖它)。
我是否需要考虑我的新文件夹结构?
尝试解决问题
所以,试图解决这个问题,我会更深入地阅读文档,我会在这里写下我会找到的内容。
答案 0 :(得分:7)
正如评论中所述,Symfony可以很好地适应所有这些结构,所以我们确实不能在这里接受一个接受的anwser,但这是我的两分钱。
说实话,最好的做法是独立于框架组织架构(主要是因为Symfony 4不再强加捆绑)。
但实际上,除了真正具体或复杂的项目之外,以#34; symfony为导向的项目更为实际。组织。
以下是我的个人偏好,并且也受到我的项目类型的强烈影响(面向CRUD,Rest API,没有强大的业务逻辑)
总的来说,我正朝着这样的结构前进:
False
原因是:
使用autowire减少服务定义 - 是的,我懒惰;-)
如果您需要将存储库或控制器注册为服务,则可以使用一个声明进行注册。
在Symfony Flex配方中,通常使用此结构。
DoctrineBundle例如初始化-src
- Controller
- Core
- Todos
- ...
- Entity
- Core
- Todos
- ...
- Repository
- Core
- Todos
- Validator (or other Symfony oriented components)
- Core
- Todos
- Others (depend on project)
- Core
- Todos
- ...
和src/Entity
文件夹以及包含实体的配方也使用此结构。
但请注意,Symfony Flex不是强制性的。它的目的主要是为了简化项目的初始化,使得框架更容易被初学者访问
答案 1 :(得分:4)
康威定律:
设计系统受限的组织... 设计是这些通信结构的副本 组织。
您应围绕组织工作的方式设计目录结构。
如果您或您的同事基于每个功能进行全栈工作,则应将每个功能的代码分组。它将使导航和代码发现更加容易。
如果您或您的同事在后端,前端,翻译等方面非常专长,则应围绕该代码组织代码。基于每个功能的目录结构将支持明确划分职责。
此外,深度应取决于您预见的项目规模。如果要由5位以上的人员花5年以上的时间,则可能应该按照工作组织的说明,按照嵌套对每个功能和每个功能进行拆分。如果这将是一个人的3个月项目,即一些简单的内部工具,则可能应该使用更扁平的结构。我还建议您坚持默认设置。
此外,我发现这篇文章内容丰富:https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
答案 2 :(得分:3)
第二种结构非常适合复杂的应用程序,业务领域分散。
Symfony 4可以通过这种方式轻松配置其应用程序。
├─ assets/
├─ bin/
│ └─ console
├─ config/
│ ├─ doctrine/
│ │ ├─ core/
│ │ └─ sample/
│ ├─ packages/
│ ├─ routes/
│ └─ validator/
│ │ ├─ core/
│ │ └─ sample/
├─ public/
│ └─ index.php
├─ src/
│ ├─ Core/
│ │ ├─ Controller/
│ │ ├─ Entity/
│ │ ├─ Repository/
│ │ └─ ...
│ ├─ Sample/
│ └─ ...
├─ templates/
│ ├─ core/
│ └─ sample/
├─ tests/
├─ translations/
├─ var/
│ ├─ cache/
│ ├─ log/
│ └─ ...
└─ vendor/
只需进行一些配置即可:服务自动接线,自动配置等...像魅力一样。
# config/packages/doctrine.yaml
doctrine:
# ...
orm:
# ...
auto_mapping: true
mappings:
App\Core:
is_bundle: false
type: yml
dir: '%kernel.project_dir%/config/doctrine/core'
prefix: 'App\Core\Entity'
alias: 'AppCore'
#config/routes/annotations.yaml
core_controllers:
resource: ../../src/Core/Controller/
type: annotation
# config/services.yaml
# But I prefer to put this on a separate config/services/_auto.yaml
services:
App\:
resource: '../../src/*/*'
exclude: '../../src/*/{Entity,Migrations,Tests,Kernel.php}'
app_controller:
namespace: App\
resource: '../../src/*/Controller'
tags: ['controller.service_arguments']