symfony4 - Symfony4 中大型项目的代码分离的最佳实践是什么？

Question

流行框架第 4 版的发布标志着项目结构的重大变化。包括官方文档，关于代码捆绑( http://symfony.com/doc/current/bundles.html )的说明如下:

In Symfony versions prior to 4.0, it was recommended to organize your own application code using bundles. This is no longer recommended and bundles should only be used to share code and features between multiple applications.

在第 2 和第 3 版中，bundle 执行了两个主要任务。 1) 如果开发人员或他们不同项目中的一组开发人员使用了一个大的重复功能，那么它可以在一个单独的包中取出并从项目转移到项目中。这种使用的一个很好的例子是任何项目中的用户系统。它包括用户模型、角色模型、权限模型(可能还有其他模型)、实体的 Controller ，以及用于登录应用程序、退出应用程序(安全策略可能同时不同)和 View 模板的 Controller 。另一个很好的例子是行政小组，其基础是相同的。 2) 从逻辑的角度来看，Symfony 在不同的目录中采用了单独的功能，因此，通过捆绑命名空间。
例如，在我过去的一个项目中，我划分了空间:用户管理系统、应用游戏化(社交网络目标)、合作伙伴空间、地理环境(用于处理 map 和通过 IP 定义城市)、支付交易环境.如下。


在我的下一个项目中，我不想使用除 Symfony4 以外的任何东西来遵循框架的新功能实现过程中的最佳实践。
如果官方文档不再坚持创建bundle，如何组织不同区域逻辑独立代码的分离？？？如果模型的所有类都存储在同一目录中，则会造成困惑并增加在大型项目结构中查找所需文件的时间。这同样适用于模板以及其他所有内容。当我使用一个函数时，我只有这个函数的下拉目录。

现在 Symfony 是否鼓励您自行决定定义类、模板等的结构？

Answer 1

作为 Symfony 的新手并从 4.2 版开始，我遇到了与@DeveloperMobile 相同的问题。

目录结构

这是我的目录结构基于指南中的建议
Symfony Best Practices版本 4.2

该建议基本上是关于结构的:

将所有 Controller 放在/src/Controller 中，除以子文件夹

不要使用捆绑包，通过命名空间组织您的代码

将 Assets 、配置、测试、模板、翻译、var/cache 和 var/log 放入根文件夹

在/src

中组织您的业务逻辑

使用 Autowiring 来自动配置应用服务。

使用依赖注入(inject)获取服务

瘦 Controller 和胖模型

所以基本上它说:是的，您可以使用子文件夹在/src 中组织您的代码，但是具有特定功能的代码，如 Controller 、实体、表单、存储库等应该在特定的目录中。

执行

root/
├─ assets/
├─ bin/
│  └─ console
├─ config/
└─ public/
│  └─ index.php
├─ src/
   ├─ Controller/
     ├─ DefaultController.php
     ├─ ...
     ├─ Api/
     │   ├─ ..
     │   └─ ..
     ├─ Backend/
     │   ├─ ..
     │   └─ ..
   ├─ Entity/
   ├─ Form/
   ├─ Repository/
   ├─ Twig/
   ├─ Utils/
   └─ Kernel.php
├─ tests/
├─ templates/
├─ translations/
├─ var/
│  ├─ cache/
│  └─ log/
└─ vendor/

Symfony 4.2 最佳实践

这是上面链接中所有建议的列表:

安装

使用 Composer 和 Symfony Flex 创建和管理 Symfony 应用程序。

使用 Symfony Skeleton 创建新的基于 Symfony 的项目。

结构

不要创建任何包来组织您的应用程序逻辑。

(Symfony 应用程序仍然可以使用第三方包(安装在 vendor/中)
添加功能，但您应该使用 PHP 命名空间而不是包
组织您自己的代码。)

配置

将与基础设施相关的配置选项定义为环境变量。在开发过程中，使用
项目根目录下的 .env 和 .env.local 文件来设置这些。

在 .env 文件中定义所有应用程序的环境变量

在 config/services.yaml 文件中定义应用程序行为相关的配置选项。

使用常量来定义很少更改的配置选项。

配置参数的名称应尽可能短，并应包含一个通用前缀
对于整个应用程序。

商业逻辑

对于大多数项目，您应该将所有代码存储在 src/目录中。在这里，您可以创建
您想要组织的任何目录:

使用 Autowiring 来自动配置应用服务。

应用程序服务的 id 应该等于它们的类名，除非你有多个
为同一类配置的服务(在这种情况下，使用蛇案例 ID)。

服务应该尽可能是私有(private)的。这会阻止你
通过 $container->get() 访问该服务。相反，你会
需要使用依赖注入(inject)。

使用 YAML 格式配置您自己的服务。

使用注解来定义 Doctrine 实体的映射信息。

Controller

使您的 Controller 扩展 Symfony 提供的 AbstractController 基础 Controller 并使用
尽可能配置路由、缓存和安全性的注释。

不要在 Controller Action 的方法中添加 Action 后缀。

不要使用@Template 注解来配置 Controller 使用的模板。
- 不要使用 $this->get() 或 $this->container->get() 从容器中获取服务。反而，
使用依赖注入(inject)。

使用 ParamConverter 技巧在简单方便时自动查询 Doctrine 实体。

模板

为您的模板使用 Twig 模板格式。

将应用程序模板存储在模板/目录中
你项目的根。

对目录和模板名称使用小写的 snake_case。

对模板名称中的部分模板使用带前缀的下划线。

在 src/Twig/目录中定义你的 Twig 扩展。您的应用程序将自动检测它们
并配置它们。

形式

将表单定义为 PHP 类。

将表单类型类放在 App\Form 命名空间中，除非您使用
其他自定义表单类，如数据转换器。

在模板中添加按钮，而不是在表单类或 Controller 中。

不要在表单中定义验证约束，而是在表单映射到的对象上定义。

国际化

将翻译文件存储在项目根目录的 translations/目录中。

为您的翻译文件使用 XLIFF 格式。

始终使用键而不是内容字符串进行翻译。

安全

除非您有两个合法不同的身份验证系统和用户(例如主站点的表单登录)
和一个仅适用于您的 API 的 token 系统)，我们建议只有一个带有匿名的防火墙条目
键启用。

使用 bcrypt 编码器散列用户的密码。

定义自定义安全投票器以实现细粒度限制。

网络 Assets

将您的 Assets 存储在项目根目录下的 assets/目录中。

使用 Webpack Encore 编译、组合和最小化 Web Assets 。

测试

定义一个功能测试，至少检查您的应用程序页面是否成功加载。

对功能测试中使用的 URL 进行硬编码，而不是使用 URL 生成器。