simple 框架

simple 框架(github)是一款简单、高效、易用的 PHP 开发框架。

为什么要有 simple 框架

学习 /锻炼 /积累 /实践 /进步
现有的框架太臃肿，部分包含了大量的 jQuery 等前端代码，而日常的后端开发工作中并用不到此类的依赖。
无存在意义的模板引擎。
DI、IoC 等设计思路下设计出的框架，学习成本较高。
做过相关压测，主流框架大部分性能较差。压测数据

从 0 到 1

基于上述逻辑，整理下一个框架所需要实现的功能，及所有功能所需要的积累。

设计思路

我认为作为一个后端底层框架，只需要为开发者提供最核心最常用的功能即可，其中包括：

composer 支持 /目录结构符合 PSR-4 规范
错误机制
config
route/mvc
request/response
DB/ORM
CLI
cookie/session
Log/curl/iptable/redis 等锦上添花的类库

框架架构图

涉及技术

composer

composer 是 PHP 用来管理依赖（ dependency ）关系的工具。可以在自己的项目中声明所依赖的外部工具库（ libraries ），Composer 会安装这些依赖的库文件。

基于 composer 开发的代码，可以让使用房快速加入自己的项目中，且可以很好的管理需要使用的版本。另外框架约定好按 PSR-4 规范后开始开发，可以省去了 autoload 的工作量（当然是有代价的，曽压测过使用 composer 的 autoload 和自己实现 autoload 的性能大概相差 15%，但是当项目足够大，需要依赖的外部资源足够多时，这个差距会逐渐的缩小）。

错误机制

保证框架运行过程中的健壮性，当框架捕获到相关异常，允许用户自定义异常处理方法，可以快速开发出满足自己业务逻辑的功能模块（例如快速实现 404/500/异常上报等功能），以及调试模式下快速定位问题。

config

用于快速读取配置文件，通过定义的预定义常量自动读取对应环境的配置。

route/mvc

route 即路由机制，通过 url 匹配一段规则后，找到对应处理的类和函数。 MVC 为模型-视图-控制器模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，已经成为 web 开发的必会标准模式。

request/response

深入了解 HTTP 协议的 request 和response

DB/ORM

选用 mysqli 或 pdo 实现 DB 的基本 query/fetch/insert_id 等操作。在此基础上，实现 SQL 语句的快捷构造封装 SQL builder （将数组生成对应 SQL 语句）。在此基础上，实现 ORM （对象-关系映射）的基本封装

mysqli
PDO

CLI

在日常的开发工作中，定时脚本任务的开发必不可少，因为便捷的开发基于 CLI 模式运行的脚本也是必须要满足的条件。

反射

cookie/session

Log/curl/Iptable/redis 等锦上添花的类库

Log 用于调试开发等方便打印日志输出。日常工作中经常需要发送一些 http 请求到特定服务器，或从某服务器拉取相关数据，curl 使用率非常频繁。在提供纯接口 server 时，对 ip 段限制的需求会经常遇到。 redis 发展到今天，无论是做缓存，还是作为稳定可靠的 DB 提供服务都毫无问题。

写在最后

目前 simple 框架不断优化、调整，已经迭代至 4.0 版本，有了近两年时间的思考和积累，某些代码的实现确实需要改进，因此有了 5.0 版本的规划和思考。准备将 5.0 版本开发过程中的一系列问题一一记录在案，并对 route、DB build、curl 等一些类库的封装思路进行详细的说明。

我也希望能有认同我观点的朋友参与进来一同思考、讨论、开发，也希望有不同观点的朋友能提出各种批评或者建议，让我们共同探讨技术，一同进步。

欢迎各种吐槽。原文地址

deepkolos

2017-07-17 12:20:00 +08:00

还有 Curl.php , 可以添加一些常用的小功能方便来使用 : 比如 auto_convert , auto_referer , 还有常用的类型转换 to_json , 我的 Curl 是这样来的使用方式

$this->Curl->get()
->url( URL , array(URL_PARAMS) )
->referer( URL )
->data() //post 的时候用的
->autoConvertTo( toEncode ) //从页面的常用位置提取 fromEncode
->convert( fromEncode , toEncode ) //手动指明 fromEncode
->headers() //设置 content-type 为非 text , 禁止自动转码, convert 依然生效
->getResponse()
->json() // 转换为 json
->base64() // 转换为 base64

Curl 的使用方式就是那么方便 , 模仿类的 AutoLoad , 对象的 AutoLoad , 因为滥用魔术方法 , 在 module/component 里面直接调用 $this->Curl 就会得到一个新的实例并挂载到当前对象的$this 下面~然后使用工具函数来配置 , 然后写一个简单的整合 get , parse , store 这个 workflow 的类 , 可以形成一个简单的爬虫框架了~

gavinczhang

2017-07-17 13:11:51 +08:00

@kancloud 第一点表示认同，但是我认为框架应该把调优的设置尽可能简洁，比如一个 debug 开关？毕竟不是所有人都能立刻找到所有框架的细节差异，再去针对性调优的，都需要不断学习了解。
第二点和第四点表示不认同，在绝大多数开发场景下，大部分框架提供的很多工具其实根本用不到，没必要为了在某些情况下可能用到的东西而提前做大的集成，这些完全可以在实际项目开发过程中通过 composer 找一些相关成熟的组件来解决。比如 YII 集成的 jQuery，比如 laravel 集成的和模板关联的表单验证。相信大部分的工作项目中，前后端足够分离的情况下，并用不到这些功能。至于模板引擎，并不能带来多少性能的提升，相反还需要前后端开发同学去学习一门只有此框架才用得到的新语法，得不偿失，php 语法本身就可以做到这些功能。
第三点，如果我没有理解错的话，提前定义好 interface，通过配置或变量的不同，创建不同的对象并注入 IoC 中，上层使用仅需要使用 IoC 中的对象即可。但是日常开发中偶尔能遇到适合这种场景的业务开发，但是框架层面，请恕我愚钝，暂时没有体会到 DI 和 IoC 为框架带来的优势，比如如果需要从 mysql 换到 oracle 或者 mysqli 换到 PDO ？但是我认真的思考过，这类庞大、重要到需要一整个团队去支撑的事情，又有多少人真的用到过？当然也可能是我的理解错了，对 DI 和 IoC 的使用场景搞错了。烦请指点，多谢。

kancloud

2017-07-17 16:47:46 +08:00

@gavinczhang 你可能没明白我的意思，不同的框架默认加载或者启动的类以及请求生命周期各有不同例如 CI 我记得是默认不开启 Session 的而其它框架默认会启动，这个对于你这种 helloworld 测试来说的话数据差异是非常大的。我的建议你的压力测试最好是使用数据库操作，这是最起码的使用场景，谁用框架来写 helloworld ？而且框架不太可能存在一键开启全部优化的情况，你觉得 apache mysql 有开启一键优化的配置么？框架的使用场景和环境太复杂了，调试模式的关闭不代表你的框架就已经进行调优了；
框架的重点不是类库，类库的问题无论目前的 Composer 还是以前的类库包都能解决，框架的处理机制和请求生命周期可以做什么以及怎么做，决定了你的功能是否强大，是否方便扩展。数据验证就算是前后端分离，后端依然要验证；
模板引擎的存在并不一定是为了给开发人员写的，否则 MVC 还有啥意义；
DI 和 IoC 的优势，如果你了解 Laravel 就明白了；
那些自诩性能很高的框架我见过很多，代价就是缺少功能以及不够完善（一旦你的用户群越来越大，你会不断增加功能满足这些需求，然后。。。），主流框架在完成相同的功能和机制的情况下，其实性能已经优化的不错了，无论 thinkphp/yii/laravel，所以应该去说你的框架如何好用，而不要用不负责任的测试数据去误导用户（讲真，现在主流框架都不在乎运行性能）

对主流框架不感冒，想开发属于自己的框架，寻求不同见解或同好朋友