### 2018 年 12 月 16 日 发布 `5.2`版本的设计初衷是致力于提供一个更规范、更易用和更高效的轻量级PHP框架,针对这个初衷我们总结归纳了一些新版框架的指导思想,不过由于目前`5.2`版本还是测试阶段,有很多方面的调整会在后续的更新中逐步改进和完善到位,也不排除会有一些额外的调整。 欢迎有更多的开发者加入新版的架构设计中来,给我们提供更多的反馈和建议。 ## 完全依赖`Composer` ThinkPHP从`5.0`开始拥抱`composer`,支持通过`composer`安装,同时也支持单独通过`git`安装,而且有自己的独立的文件自动加载机制,所以说并不依赖`composer`,这也是官方把`thinkphp`目录放到项目根目录的原因之一。 经过两个版本的用户培养工作,`5.2`版本将彻底依赖`composer`安装,并且由`composer`完全接管框架的自动加载,原来的`Loader`类也已经取消了。框架目录按照`composer`的安装规范纳入`vendor`目录。 ## 基于`7.1+`强类型约束 基于PHP`7.1+`版本的设计主要是为了使用PHP7的强类型约束功能,`7.1`对方法变量类型的支持已经很完善了。而且`5.2`版本也率先在主流框架中开启了严格模式,所有的变量和返回值都会强制进行类型检查,此举可以帮助开发者提前发现一些问题隐患,从而更规范的进行变量使用。 >[danger] 基于`7.1+`不等于不支持PHP`7.2`甚至更高版本,因为核心框架内部没有使用`7.2`版本的任何特性。 ## 用法尽量统一 早先版本的ThinkPHP虽然功能强大,但用法太多一直为开发者所诟病。实现同一个功能有太多的用法,每个人都有自己的一套用法,导致项目代码规范不统一。`5.2`在设计之初,就奔着精简和统一用法的决心,让核心的用法尽量统一,便于团队形成一致的使用规范。 一个很典型的例子就是新版的数据查询取消了`get`/`all`,无论是`Db`类还是模型都统一使用`find`/`select`方法(事实上,5.1最新LTS版本已经可以统一使用了,不过没有废除`get`/`all`),这样的例子还有很多,暂时就不一一叙述了。 另外一个用法统一的表现是在一些方法的参数上,不再提供多种用法,例如模板变量的赋值之前版本下面两种方式都支持: ``` $this->assign('name', 'think'); $this->assign(['name' => 'think']); ``` 现在只能使用后者,统一传入数组参数。 ## 惯例重于配置,规范重于灵活 ThinkPHP`5.0`框架在很多方面比较灵活,但这样容易导致缺乏规范,`5.1`版本由于取消了系统常量对框架目录的自定义做了严格的规范,这一现象有所缓解。`5.2`版本更侧重于惯例和规范,而不盲目提供太灵活的设置和调用。 ## 拥抱`PSR`规范,但不盲目 新版会遵循更多的`PSR`规范,但鉴于很多旧的`PSR`官方库的接口定义版本过旧导致没法进行强类型约束,因此不排除会做一些可能的变通。 想必[PHP FIG](https://github.com/php-fig)组织制定PSR规范的同时,给出的接口规范只是一种示例而非强制吧。 ## 提供建议使用的助手函数 对于助手函数的使用,仅提供推荐和允许使用的,清理一些不必要或者不推荐的。 ## 组件化和可组装原则 关于核心是否需要组件化一直在内部争论的部分,在现代开发模式中,已经完全可以基于`composer`里的各种组件组装自己的框架,ThinkPHP也会致力于提供各种组件,但不一定确保核心框架是完全组件化。但可能的处理方式是尽量在内部形成低耦合和高内聚,而非完全的组件化。核心非必需组件可替换及组装,同时低于20%的使用场景内部独立设计为可配置替换,低于5%的功能场景尤其是增加性能开销的则考虑直接从核心移除,需要的时候通过扩展继续使用。 比如,路由检查、请求缓存以及多语言支持功能已经纳入`AppInit`事件监听设计,完全可以在应用中自行控制和替换。 ## 功能精简,性能提升 之前版本的框架设计了很多很多细节的功能,但使用的频率非常之低,占用了内存不说,对于不需要这些功能的开发者来说,阅读文档和理解一堆配置参数也会带来更多的困惑。事实上,很少有项目能用到核心框架超过50%的功能,此次版本的功能精简对于大部分应用开发而言,几乎没有任何的影响,但很明显能够感受到性能的提升。