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

Question

流行框架第4版的发布标志着项目结构的资本变化。包括官方文档，注意以下关于代码捆绑（http://symfony.com/doc/current/bundles.html）：

在4.0之前的Symfony版本中，建议使用bundle组织您自己的应用程序代码。不再推荐使用此选项，并且仅应使用捆绑包在多个应用程序之间共享代码和功能。

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

在我的下一个项目中，我不想使用除Symfony4之外的任何内容来在实现其新功能时遵循框架的最佳实践。如果官方文档不再坚持创建捆绑包，我怎样才能在不同区域组织逻辑上独立的代码分离？如果模型的所有类都存储在同一目录中，则会产生混淆并增加在大型项目结构中查找所需文件的时间。这同样适用于模板以及其他所有内容。当我使用一个功能时，我只下载了此功能的目录。

现在，Symfony是否鼓励您根据自己的判断定义类，模板等的结构？

Answer 1

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

目录结构

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

该建议基本上讲述了结构：

• 将所有控制器放在/ src / Controller中，除以子文件夹
• 不要使用Bundles，按命名空间组织代码
• 将资产，配置，测试，模板，翻译，var / cache和var / log放在根文件夹中
• 在/ src中组织您的业务逻辑
• 使用自动装配自动配置应用程序服务。
• 使用依赖注入来获取服务
• 薄控制器和胖模型

基本上它说：是的，您可以使用子文件夹在/ src中组织您的代码，但具有某些功能的代码（如Controller，Entity，Form，Repository等）应该在特定的目录中。

履行

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/

Best Practice Symfony 4.2

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

安装

• 使用Composer和Symfony Flex创建和管理Symfony应用程序。
• 使用Symfony Skeleton创建基于Symfony的新项目。

结构体

• 不要创建任何捆绑来组织应用程序逻辑。 （Symfony应用程序仍然可以使用第三方软件包（安装在vendor /中）来添加功能，但是您应该使用PHP命名空间而不是bundle来组织自己的代码。）

组态

• 将与基础架构相关的配置选项定义为环境变量。在开发期间，使用项目根目录中的.env和.env.local文件来设置这些文件。
• 在.env文件中定义所有应用程序的环境变量
• 在config / services.yaml文件中定义与应用程序行为相关的配置选项。
• 使用常量来定义很少更改的配置选项。
• 配置参数的名称应尽可能短，并且应包含整个应用程序的公共前缀。

商业逻辑

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

• 使用自动装配自动配置应用程序服务。
• 应用程序服务的id应该等于它们的类名，除非您为同一个类配置了多个服务（在这种情况下，使用snake case id）。
• 服务应尽可能私密。这将阻止您通过$ container-> get（）访问该服务。相反，您将需要使用依赖注入。
• 使用YAML格式配置您自己的服务。
• 使用注释定义Doctrine实体的映射信息。

控制器

• 使控制器扩展Symfony提供的AbstractController基本控制器，并尽可能使用注释配置路由，缓存和安全性。
• 不要将Action后缀添加到控制器操作的方法中。
• 不要使用@Template注释来配置控制器使用的模板。 - 不要使用$ this-> get（）或$ this-> container-> get（）来从容器中获取服务。相反，使用依赖注入。
• 使用ParamConverter技巧可以在简单方便的情况下自动查询Doctrine实体。

模板

• 为模板使用Twig模板格式。
• 将应用程序模板存储在项目根目录的templates /目录中。
• 使用lowercased snake_case作为目录和模板名称。
• 对模板名称中的部分模板使用带前缀的下划线。
• 在src / Twig /目录中定义Twig扩展。您的应用程序将自动检测并配置它们。

形式

• 将表单定义为PHP类。
• 将表单类型类放在App \ Form命名空间中，除非您使用其他自定义表单类，如数据转换器。
• 在模板中添加按钮，而不是在表单类或控制器中。
• 不要在表单中定义验证约束，而是在表单映射到的对象上定义验证约束。

国际化

• 将翻译文件存储在项目根目录的translations /目录中。
• 将XLIFF格式用于翻译文件。
• 始终使用键进行翻译而不是内容字符串。

安全

• 除非您有两个合法不同的身份验证系统和用户（例如，主站点的表单登录和API的令牌系统），我们建议只启用一个防火墙条目并启用匿名密钥。
• 使用bcrypt编码器来散列用户的密码。
• 定义自定义安全选民以实现细粒度限制。

网络资产

• 将资产存储在项目根目录的assets /目录中。
• 使用Webpack Encore编译，组合和最小化Web资产。

测试

• 定义一个功能测试，至少检查您的应用程序页面是否成功加载。
• 对功能测试中使用的URL进行硬编码，而不是使用URL生成器。

Answer 2

正如他们所说（source），你定义了自己的结构，不建议重构你所有的实际应用

我们的建议合理而明确：您可以将这些最佳实践用于新应用程序，但您不应重构现有应用程序以遵守这些最佳实践。

我希望你能得到答案:)

Answer 3

每个大型项目都应分为后端，前端，api或服务，以及格式之间的变量键，错误代码键和缓存键控制，因此每个项目都有自己的依赖关系，它缩短了维护时间，开发时间，等......

backend.mysite.com

www.mysite (frontend)

api.mysite.com

Answer 4

正如@Nelson所说，无需重构您当前的应用程序。

如果它是一个新项目，你基本上可以做你想要的。

例如，您可以像这样制作控制器

src
   - Controller
      - Bundle1 //Bundle is not the right word here, it's just to say you can separate your code in independents parts like this
      - Bundle2

逻辑类，模型（实体/文档）等同样的事情，等等。

您只需更改services.yaml文件以指示控制器的位置，并定义您在哪些文件夹中具有服务（可注入类）等。

您基本上可以自由地做任何你想做的事情，即使它建议遵循他们的演示应用程序（src/controller/*，src/Form/*等）

这个问题已经过时了，我希望它仍能帮助你。