在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最佳实践指南》4.2版的建议

建议基本上说一下结构：

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

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

实作

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骨架创建基于Symfony的新项目。

结构体

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

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

组态

• 将与基础架构相关的配置选项定义为环境变量。在开发过程中，请在项目的根目录下使用.env和.env.local文件进行设置。

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

• 在config / services.yaml文件中定义与应用程序行为相关的配置选项。
• 使用常量定义很少更改的配置选项。
• 配置参数的名称应尽可能短，并且应包括整个应用程序的公共前缀。

商业逻辑

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

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

控制器

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

范本

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

形式

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

国际化

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

安全

• 除非您有两个合法不同的身份验证系统和用户（例如，主站点的表单登录和仅API的令牌系统），否则我们建议仅启用一个启用了匿名密钥的防火墙条目。
• 使用bcrypt编码器对用户密码进行哈希处理。
• 定义自定义安全投票器以实施细粒度的限制。

网络资产

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

测验

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