Symfony 4:如何组织文件夹结构(即您的业务逻辑)

Question

在Symfony中,建议最佳实践不要使用bundle来组织业务逻辑.

只有在其中的代码要在其他应用程序中按原样重用时,才应使用这些bundle:

但捆绑包意味着可以作为独立软件重用的东西.如果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
       - ...
   - ...

这同样适用于项目目录结构中描述的其他根文件夹(关于如何覆盖它).

是否有任何规则或约束我必须考虑决定我的新文件夹结构？

试图解决问题

所以,试图解决这个问题,我会在文档中更深入,我会在这里写下我会发现的内容.

• 控制器:使用精细的控制器配置.
• 枝条:
• 实体:使用 orm.entity_managers.some_em.mappings.mapping_name

---

Answer 1

正如评论中所述,Symfony可以很好地适应所有这些结构,所以我们确实不能在这里接受一个接受的anwser,但这是我的两分钱.

说实话,最好的做法是独立于框架组织架构(主要是因为Symfony 4不再强加捆绑).

但事实上,除了真正具体或复杂的项目外,拥有一个"面向symfony"的组织将更加实际.

以下是我个人的偏好,也受到我的项目类型的强烈影响(面向CRUD,Rest API,没有强大的业务逻辑)

总的来说,我正朝着这样的结构前进:

-src
   - Controller
       - Core
       - Todos
       - ...
   - Entity
       - Core
       - Todos
       - ...
   - Repository
       - Core
       - Todos
   - Validator (or other Symfony oriented components)
       - Core
       - Todos
   - Others (depend on project)
       - Core
       - Todos
   - ...

原因是:

• 使用autowire减少服务定义 - 是的,我很懒;-)

  如果您需要将存储库或控制器注册为服务,则可以使用一个声明来完成.

• 在Symfony Flex配方中,通常使用此结构.

  DoctrineBundle例如初始化src/Entity以及src/Repository包含实体的文件夹和配方也使用此结构.

但请注意,Symfony Flex不是强制性的.它的目的主要是为了简化项目的初始化,使得框架更容易被初学者访问

Answer 2

康韦定律：

设计系统的组织被限制产生设计，这些设计是这些组织的通信结构的副本。

您应该围绕组织工作的方式设计目录结构。

如果您或您的同事按功能全栈工作，则应按功能对代码进行分组。这将使导航和代码发现更加容易。

如果您或您的同事在后端，前端，翻译等方面非常专长，则应围绕该代码组织代码。基于每个功能的目录结构将支持明确划分职责。

此外，深度应取决于您预见的项目规模。如果要由5位以上的人员花5年以上的时间，则可能应该按照工作组织的说明，按照嵌套对每个要素和每个功能进行拆分。如果这将是一个人的3个月项目，即一些简单的内部工具，则可能应该使用更扁平的结构。我还建议坚持默认设置。

此外，我发现本文内容丰富：https：//blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

Answer 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']