2

在将现有应用程序升级到 Flex部分，Symfony 4 文档指出：

  1. 将原始源代码src/{App,...}Bundle/移至src/并更新每个 PHP 文件的名称空间App\...（高级 IDE 可以自动执行此操作）。

第一部分“将原始源代码移出src/{App,...}Bundle/”很清楚。我们可以这样理解一个目录结构：

sf3-project/
├── src/
    ├── AppBundle/
        ├── Controller/
            ├── MyFirstController.php
            └── MySecondController.php
        └── ...
    └── ApiBundle/
        ├── Controller/
            ├── MyFirstController.php
            └── MySecondController.php
        └── ...

但是，我不清楚第二部分“将src/每个 PHP 文件的名称空间更新为App\...” ，尤其是关于建议的结构。

据我了解，它建议将每个Controller/目录的内容复制到一个目录中。如果是这样，如何处理具有相同名称的控制器？我们应该添加以前一个包的前缀作为名称的子目录吗？

symfony 演示项目似乎建议这样做，Admin/因为Controller/.

我们应该如何将之前的目录结构升级为以下？

sf4-project/
├── src/
    ├── Controller/
    │    └── ...
    ├── ...
    └── Kernel.php

我们可以注意到这个sf4-project示例遵循逐层结构的包，就像在文档中一样。我也想知道我们是否可以通过功能结构轻松使用包。

那么，Symfony 4 对于逐层封装和逐特征结构封装的建议方法是什么？

4

1 回答 1

1

Symfony 和捆绑包

Symfony 2 提到“Bundles 是 symfony 框架中的一等公民”。所以这是一个有点固执己见的框架，其中一切都是捆绑包，甚至是你的应用程序。

后来，良好实践建议捆绑包应该只是应用程序的可重用组件，但我们继续使用捆绑包来组织代码。

这导致许多开发人员一遍又一遍地复制默认的包结构，而忽略了对他们更好的东西。仅仅因为它可以帮助您不必考虑架构，您运行一个命令并生成所有文件夹结构和控制器。

如果您查看（设计良好，与其他框架兼容）symfony 包，您会发现它们至少有 2 个包。一个包含代码、类、服务等，另一个包在 symfony 中配置所有这些。示例：Doctrine、jms/serializer、KnpMenu 等

捆绑更少的 symfony

我相信转向更少的 symfony 的目标是：

  • 与其他框架的简单可重用性：Laravel、Silex?、Zend
  • 让您思考并为您要解决的项目设计最佳架构

因此，从 Symfony 捆绑包中转移到完全复制 symfony 新版本作为默认/演示架构的内容对您毫无帮助。

我的建议是：忘记 Symfony 4 的默认/推荐设置

计划你应该如何组织你的代码：定义你的包和库，以及把你的代码放在哪里，以便于开发、维护和测试。

尽量减少包和库之间的依赖关系。

决定你自己的权衡，然后如果你需要重构就去做。

如果您不喜欢计划自己的架构，或者您想稍后再做，请不要重构它。

查看关于软件架构的 Uncle Bob 视频：https ://www.youtube.com/watch?v=HhNIttd87xs

于 2017-12-19T19:27:06.473 回答