用Composer搭建PHP框架（一）

前言

PHP一直以性能问题被人诟病，它的快速更新使得它在性能上相对较旧的地方有了质的提升，特别是PHP7的出现让phper们仿佛又看到了希望。

和PHP5.2相比，新增版本逐步有了namespace，有了更多的psr规范，有了原生闭包，新增了很多魔术方法等就不一一列举，我们发现新的特性出来都是为了解决某些问题的，使用CLI内置的web server不需要为了某个临时项目去单独布置一套环境了，例如namespace解决用下划线分割类名以便自动载入和类名冲突的问题等，关于更多新的特性，我们可以去浏览PHP官网寻找答案。

Composer简介

现代php发展中，一定少不了composer,几乎现在所有的框架都支持了composer,古老的CodeIgniter框架在其3.0也引入了composer。

什么是Composer?

Composer是一个杰出的PHP包依赖管理工具，它类似Nodejs的npm，composer包含一个依赖管理器，用来处理开发包之间复杂的依赖关系，它还包含了下载器，安装器等等。Packagist 是 Composer 的默认的开发包仓库。你可以在这里找到自己适用的包，你也可以将自己的代码包提交到 packagist，让更多的人去使用你的包提供的便捷，这也是Composer的运作理念。

Composer的简单使用

作为一个用户，我们只需要在项目下的composer.json文件下声明当前项目需要用到的依赖开发包然后运行composer install安装依赖包即可，比如：我需要加载一个monolog包，

{    "required":{        "monolog/monolog":"1.2.*"    }}

也可以直接在项目目录直接使用 composer required monolog/monolog 即可，你会发现你的项目下多了一个vendor文件夹，同样的道理，你可以修改required里面的版本号来执行 composer update 更新所依赖的版本号，也可以直接执行 composer update 或者在后面指定依赖包名来更新到依赖包的最新版本。如果你需要使用所更新下来的包则直接在你的PHP文件引入 vendor 下的autoload.php即可，这使得你很容易使用第三方代码。

事实上 Composer 不仅仅只有这些功能，它提供的 autoload 选项支持多种自动加载类型：

1. classmap
2. psr-0
3. psr-4
4. files

classmap 一般用来对某些开发类自动加载，psr-4则是项目代码的自动加载，psr-0基本由psr-4替代，files模式主要针对全局helper之类的function载入，配置完成后执行composer dumpautoload即可，表面上看起来 Composer 为我们所做的这么多只需要几句命令即可实现，其实它背后执行的都是PHP代码,有兴趣的可以追踪到vendor的autoload.php继续探索它的自动加载的奥妙。

使用composer搭建一个属于自己的框架

通过上面的了解，我们知道了通过 Composer 能获取众多的PHP包依赖，既然这样我们拥有这这么多优秀的PHP包，我们是不是可以把这些包组装起来为自己所用呢，接下来我带大家一起来利用 Composer 以及一些优秀的包来搭建属于我们自己的框架。在开始之前，可以请大家思考一下PHP框架都有哪些常用的东西组成呢？

前面了解了Composer的一些运作方式和大概使用方式，这节我们来讨论下我们要如何来构建自己的现代PHP框架，和传统框架对比不会有太大的差别，只是我们都建立在composer之上，传统业务型框架至少需要有“路由”、“ORM”、“模板”这几个必不可少的组件，如果只是做 API 开发，模板这个组件也可以不需要，让我们来分析下现代PHP框架都有哪些组件：

• HTTP组件

框架以 Request -> Response 的一个HTTP请求事务为依据，现代PHP的 Request 应该符合 PSR-7标准；

• 路由

我们说每一个请求的URI对应的都是一个资源操作，如何区分他们的区别，区别他们的行为，这一切都可以基于框架的PSR-7请求做出对应的响应，我们称之为框架路由；

• 中间件

老的框架没有中间件的概念，取而代之的是钩子概念，中间件可以理解为一个请求在进入应用之前(before)和之后(after)但必须在响应之前需要做的事情，最常用的场景就是用来做一些请求过滤，可以是参数过滤、安全策略限制等，只要是请求带来的属性都可以进行过滤或其他处理。并且中间件可以有多个；

• 服务容器

通俗的讲，容器可以比作一个大盒子，我们可以把我们需要用到的类的实例都注册到盒子里，当我们想用的时候直接问它要就行，当然容器实现的并没有我们说的这么简单，它有它的一些内部繁琐的实现机制，比如：服务的单例、绑定与解绑等；

• ORM

没有ORM的框架不是好框架（逃~），就让它解放你的双手，不再手写Sql语句，最主要的是一个强大的ORM可以让你提高数倍效率，还能远离注入漏洞；

• 配置文件

对于一些一成不变的配置，例如数据库链接信息等，将它放在配置文件，既可以提高程序的灵活性，也方便了配置属性的集中式管理；

• 错误处理

框架需要一个优雅的错误处理是有必要的，友好的提示总会给人好的印象；

• 模板

使用模板将程序分层，后端可以专注业务逻辑的开发，稍微熟悉点模板语法的都可以做前端嵌套，而且模板语法非常简单方便，当然API开发就没他们什么事儿了；

• 缓存

业务到一定规模了，到达一定的 RPS 则需要根据业务对一些数据缓存起来，具体的缓存形式有很多，文件、数据库等都可以；对于框架来说最好能有一层上层封装来适配地下的各种缓存形式；

列出了这么多，并不是说百分之百都需要的，但这次我打算把这些组件一个个添砖加瓦的砌成一个属于自己的自定义框架，在接下来的过程中，我只会少量的去分析组件(包)的一些原理，我也不会使用一些太过于“好用”的组件，主要是希望更多的是让我们能在搭建框架的同时，自己也能写一点代码，也算作为一种参与感。