Symfony 4:如何组织文件夹结构(即业务逻辑)
在Symfony最佳做法中，建议不要使用包来组织业务逻辑。
只有当它们中的代码要像在其他应用程序中那样被重用时，才应该使用这些包：
但是捆绑包意味着可以作为一个独立的软件来重用。如果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
回答 3
Stack Overflow用户
发布于 2018-03-16 12:25:46
正如注释中所述，Symfony可以很好地处理所有这些结构，因此我们确实不能在这里有一个被接受的分析器，但这是我的两分钱。
老实说，最好的实践是独立于框架来组织体系结构(这主要是因为这个原因，Symfony 4不再强制使用包)。
但事实上，除了非常具体或复杂的项目外，建立一个“面向symfony”的组织将更加实用。
下面是我的个人喜好，它也受到我的项目(面向CRUD，Rest，没有强大的业务逻辑)的类型的强烈影响。
总的来说，我正朝着这样的结构迈进：
-src
- Controller
- Core
- Todos
- ...
- Entity
- Core
- Todos
- ...
- Repository
- Core
- Todos
- Validator (or other Symfony oriented components)
- Core
- Todos
- Others (depend on project)
- Core
- Todos
- ...原因是：
- 少用自动定义的服务-是的，我很懒;-) 如果需要将存储库或控制器注册为服务，则可以使用一个声明来完成。
- 在Symfony Flex食谱中，通常使用的是这种结构。
例如，DoctrineBundle初始化包含实体的
src/Entity和src/Repository文件夹和菜谱也使用此结构。
但是要记住，Symfony Flex并不是强制性的。其主要目的是简化项目的init，使框架更易于初学者访问。
Stack Overflow用户
发布于 2018-07-04 14:01:57
康威定律：
设计系统的组织..。被限制生产设计，这些设计是这些组织的通信结构的副本。
您应该围绕如何组织工作来设计您的目录结构。
如果您或您的同事在每个功能的基础上进行全堆栈工作，那么您应该将您的代码按特性分组。它将使导航和代码发现更容易。
如果您或您的同事在后端、前端、翻译等方面有很好的专门知识，那么您应该围绕这一点组织您的代码。基于每个功能的目录结构将支持明确的职责分工。
此外，深度应该取决于你预测一个项目有多大。如果这将是5+年5+人员的工作，那么您可能应该按照工作组织的不同，在每个特性和每个函数上进行嵌套分割。如果这将是一个人3个月的项目，即一些简单的内部工具，你可能应该采用更平坦的结构。我还建议坚持违约。
此外，我发现这篇文章内容丰富：https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
Stack Overflow用户
发布于 2018-08-27 01:53:05
第二种结构非常适合复杂的应用程序，业务领域分裂。
使用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']https://stackoverflow.com/questions/47594542
复制相似问题
腾讯云开发者
