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

Question

建议在Symfony Best Practices中不要使用包来组织业务逻辑。

仅当要在其他应用程序中按原样重用其中的代码时，才应使用 bundle 软件:

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.

因此，当我将应用程序从Symfony 3.3升级到Symfony 4时，我认为现在是重组我的代码的正确时机。

目前，我遵循“ bundle 结构”:

- 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中描述的其他根文件夹(有关如何覆盖它)。

在确定新的文件夹结构时，是否需要考虑任何规则或约束？

尝试解决问题

因此，为解决问题，我将在文档中做更深入的介绍，并将在此写下我会发现的内容。

Controller :使用fine grained configuration of controllers。

嫩枝:

实体:使用 orm.entity_managers.some_em.mappings.mapping_name

Answer 1

如评论中所述，Symfony可以很好地与所有这些结构配合使用，因此实际上我们在这里无法获得公认的答案，但这是我的两分钱。

老实说，最佳实践是独立于框架组织架构(主要是因为这个原因，Symfony 4不再强加 bundle 软件)。

但是实际上，除了真正特定或复杂的项目之外，拥有一个“面向符号的”组织将更加实用。

接下来是我的个人喜好，并且也受到我的项目(面向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减少服务定义-是的，我很懒;-)

如果您需要将存储库或 Controller 注册为服务，则可以使用一个声明来完成。

在Symfony Flex配方中，通常使用此结构。

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

但是请记住，Symfony Flex不是强制性的。它的目的主要是简化项目的初始化过程，并使初学者更易于使用框架。