如何将Symfony 3捆绑应用程序升级到Symfony 4无捆绑应用程序?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何将Symfony 3捆绑应用程序升级到Symfony 4无捆绑应用程序?相关的知识,希望对你有一定的参考价值。
在Upgrading Existing Applications to Flex部分,Symfony 4文档指出:
- 将原始源代码从
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 demo project下的Admin/
目录,Controller/
似乎暗示了这一点。
我们应该如何将以前的目录结构升级到以下目录?
sf4-project/
├── src/
├── Controller/
│ └── ...
├── ...
└── Kernel.php
我们可以注意到这个sf4项目示例遵循逐层结构,就像在文档中一样。我也想知道我们是否可以通过功能结构轻松使用包。
那么,Symfony 4对于逐层和按包特征结构的建议方式是什么?
Symfony和捆绑
Symfony 2提到“Bundles是symfony框架中的一等公民”。所以这是一个有点自以为是的框架,即使你的应用程序,一切都是捆绑。
后来的良好实践建议捆绑应该只是应用程序的可重用组件,但我们继续使用捆绑包来组织代码。
这创造了许多开发人员不断地复制默认的bundle结构,忽略了对他们更有效的方法。只是因为它可以帮助您不必考虑体系结构,您可以运行命令并生成所有文件夹结构和控制器。
如果您看一下(设计良好,与其他框架兼容)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
以上是关于如何将Symfony 3捆绑应用程序升级到Symfony 4无捆绑应用程序?的主要内容,如果未能解决你的问题,请参考以下文章
Symfony2:使用 FOSUserBundle 时如何在控制器内获取用户对象?
Windows 安装 Symfony 2.2 框架 - 安装成功 !!