作为一个 Symfony 框架的老用户,symfony(注意那个年代 s 还是小写的) 诞生于 PHP <5.2 时代,跟 PHP 5.3 时代的 Symfony2 相比简直天壤之别。而最近 Symfony3 的发布让我发现,似乎改动也不是很大,心想该不是 Symfony 也学 Chrome 那样加版本号了吧?这几天 Symfony 开发组老大又开始说 Symfony4 要发布的事情,但内容倒不至于让我太失望,的确变化也不小。下面就来说说老大哥提到了 SF4 到底有哪些变化。
按 SF 老大的说法:
Symfony 3.0 = Symfony 2.8 – 不建议使用的功能
Symfony 4.0 = Symfony 3.4 – 不建议使用的功能 + 新的开发方式
或者
Symfony 4.0 = Symfony 3.0 + 所有 3.x 添加的新功能 – 不建议使用的功能 + 新的开发方式
同时,SF4 将要求使用 PHP 7
SF4 要解决的问题
- 安装 bundle 很烦人:你需要
- 使用 composer 先下载 bundle;
- 在
AppKernel
里注册 bundle; - 可能需要注册一些路由规则;
- 添加此 bundle 的相关配置
- 删除 bundle 更烦人,你需要将安装过程全部重新逆向操作一遍,稍不注意漏了点什么,就会报错。
- 当前的 SF 标准框架(Symfony Standard Edition)还不够好。SF 标准框架为了展示基本用法,默认添加了很多东西,比如数据库,模板引擎,邮件发送功能等,但目前这些功能可能已经没那么重要了(比如目前很多服务器仅仅为客户端提供 REST 接口,模板其实不需要),而且还包含诸如 LICENSE,README,以及 .htaccess 这些可能没用的文件,总之要删除这些文件和组件也是一件麻烦事。
- SF 的发行版生态圈没建立起来,老大的说法是因为基于 SF 的发行版还不够灵活。
而理想的状态,应该是新手不需要花太长时间去开始了解一个新框架,而老鸟不应该花太多时间去调整框架,目前的 SF 框架还不具备这个特点(我的理解是,因为 SF 标准框架包含的组件太多,导致新手需要了解的东西太多才能开始新框架,而老手需要不厌其烦将默认自带的不需要的组件去掉来匹配项目需求)。
基于某种框架的发行版比如 sf-cms 系统,可以理解为是对 SF 框架的一种继承,但是否基于组合的思路会更好?比如我只需要一个 API 接口的发行版组合上一个后台管理系统。
新世界的大门即将打开…… Symfony Flex 将成为一种新的开发方式,不管是创建一个微型框架,还是由无数的依赖组件组合起来的庞大项目,都能轻松实现,并且还能自动添加 / 删除 bundle,管理配置文件,并且帮你发现新的优秀的 bundle。
微框架 VS 巨型框架
关于微框架和巨型框架的争论一直未停止,对于传统的 SF 框架来说,可能更靠近『巨型框架』,因为 SF 框架包含了整个 Symfony 组件库,以及一些核心 bundle,以及还有 twig 或者 web profiler 这些库,其实如果你是给移动端开发接口,你也可以把某些不需要的库比如 twig 删掉。
有很多程序猿感觉 SF 框架的 vendor 目录占了不少磁盘空间,从而想当然觉得 SF 是一个臃肿的框架,这只是感觉而已(说实话我已经无力吐槽库文件大就觉得框架臃肿所以性能低下这种说法了,说得好像你电脑变卡是因为磁盘里存的毛片儿太多一样)。
而 Silex(Symfony 老大写的另外一个微框架)就是需要什么组件才安装什么组件,但实际运用也并没有比 SF 框架快和轻巧。不过 Flex 将会更接近 Silex 框架。
SF4 框架将不会默认安装所有的 Symfony 组件,而是跟 Silex 类似,让用户自己选取需要的组件。这么做不是为了精简 vendor 目录,而是为了实现更多很厉害的功能。
比如安装 bundle 的时候自动进行配置,自动将默认的配置写到配置文件里,而且会根据你其他组件来调整配置。
比如现在 FrameworkBundle 默认只能把 Form 功能打开,因为 FrameworkBundle 没有办法知道你是否需要 Form 提供的功能,但 SF4 不再默认安装全部 Symfony 组件,所以 FrameworkBundle 就可以根据你是否安装了 Form 组件来判断是否提供 Form 功能。
这样也可以防止有些没用的组件还在开启的状态,让性能稍微得到提升。
接下来,删除组件也可以做到自动删除配置文件。比如现在检查框架运行环境,是从 SensioDistributionBundle 里复制到 web/config.php
的,检查完,部署的时候还得自己记得删掉,SF4 如果要检查环境,就仅仅是安装 symfony/requirements-checker,检查完毕之后,删除这个工具,所有相关的文件都会被自动的删除而不用自己去清理。
在 composer 安装某个库的时候,SensioDistributionBundle 还提供了一些自动运行的命令,比如清除缓存,安装静态文件到 web 目录。其实这感觉像是硬编码了一些命令到 composer.json,而 SF4 是可以按用户的需求自己编写运行一些命令的。
最后,相对于目前的 SF 都必须要用 Bundle 来开始项目,比如常见的 AppBundle,SF4 将支持 bundle-less,这会让人感觉上手更简单。
最佳实践
Symfony 4 将拥抱更多的开源世界的标准工具来简化开发。
当 PHP 开始有 Fig 组织时(PHP 开发标准发布组织),作为一个框架,Symfony 已经采用并实现了大部分标准。
SF4 将采用环境变量来替代现在的 parameters.yml
文件,通过标准的 .env 文件导入到环境的方式。因为 .env 属于整个 linux 世界导入配置的标准方式,不仅可以让配置可以不分语言不分框架在各个项目中重用,而且还可以使用现有的工具来维护它,当然,如果配置有变化,也不需要重新部署项目(对于 Symfony 来说就是清除缓存),只要把环境变量的值改了就行了。而且也不再需要两个前端控制器,分别用于开发和生产环境,一个控制器就搞定。命令也不再需要 --debug
或者 -e prod
表示环境的参数。
另外,make
也是著名的标准工具,SF4 将使用 make
,通过 Makefile
来定义一些任务或者命令。
目录结构
测试文件将移到项目目录的 tests 目录下;
模板文件将放在 templates 目录下;
配置文件将放在 etc 目录;
源代码放在 src 目录;
类似 SF3,生成的缓存文件将放在 var 目录。但不同于 SF3 的是,临时文件不再放在 var 目录里,而是放在 var/tmp 或者直接放在 unix 系统的 /tmp 目录下;
web 文件放在 web 目录。除了前端控制器,之前版本的 config.php|.htaccess|favicon.ico
等文件都将默认不安装。
自动化工作流程
Symfony 4 将由 Symfony Flex 加持,flex 是简约而不简单的 composer 插件。默认 Symfony 框架只有两个依赖,symfony/flex 和 symfony/framework-bundle,其他都是可选依赖。
我们大部分的项目都不可能只依赖 FrameworkBundle。以前安装和配置所有的依赖包烦人无聊又容易出错,包括一些 Symfony 标准框架里的依赖也是这样。
而这就是可以体现 flex 牛逼的地方。
当你用 composer 安装依赖包的时候,flex 通过钩子程序自动帮你做好配置,包括自动注册 bundle,自动添加配置项,自动设置环境变量,自动添加 MakeFile 的任务,自动添加 composer 钩子命令,自动添加 .gitignore 项,以及自定义安装完成后显示给用户的提示信息。
这些都是通过 flex 的各种『食谱(Recipes)』提供的功能,当然,用户自己也是可以添加『食谱』的。
下一篇文章将给大家展现基于 Symfony 4 的 Demo。
via https://www.chrisyue.com/what-to-expect-of-symfony-4.html