更新:
官方中文文档地址更新为: http://betephp.com/zh
玉河CC 提到的Error,Exception处理bug已修复;
拆分Action改回到Controller方式;
以下为原问题
框架网站地址: http://betephp.com/
Github: https://github.com/betephp/be...
问题1. 将MVC里Controller的action分离成一个个Action文件,一个Action对应一个请求接口,这样做是否是否会影响开发者的使用习惯?
问题2. 框架只包含了路由,Action,数据库,日志等基础组件,没有包含用户认证,表单生成等特性,用户认证等逻辑每个业务可能包含不同逻辑,我们认为应该交给开发者自己实现,有些框架提供表单生成方法,我们认为有点php干了前段的活,从前后端分离角度考虑,视图渲染应该只包含展示数据的逻辑。你怎么看?
问题3. 为了性能考虑,框架不依赖任何其他composer库,纯框架自己实现,文件数量少,文件IO较低,因此性能比其他库框架相比高处100%到200%。
本来是准备自己测试一下框架与 lumen、slim 的性能对比,不过改了不少地方一直没运行起来,放弃了。
看来问主就是作者啦,那我就直接提出问题好了。
ps. 以下问题都是基于作者是希望做一个开源框架为基础的,如果只是自己使用,就像 @aa杨 所说的,自己用的爽就好
ps2. 代码用的 master,依赖 betephp/framework 版本 1.0.1
代码本身问题:
框架不支持
PHP7
。主要表现为throw
个Error
就不知道怎么处理。命名空间很多地方没加好,最明显的就是 throw new \Exception() 经常给不加 \ 。
框架没有测试代码。没做好测试的话,实在是不敢用。
性能测试方面:
看了一下框架的结构,感觉对标
laravel
和Yii2
有点过分了,而且laravel
的数据有点过分低了。文件数量。文件数量不能把不会使用的文件包含进来,最好按执行时实际加载了多少文件来对比。另外文件数量都不算什么大事了,生产环境不开
opcache
的很少吧。设计理念方面:
Controller 强制拆成 Action。感觉就是从一个强制跳到了另一个更大的强制里。这更像一个特定项目的需求而不是一个通用需求。
就写这么多。不过还是鼓励下作者开源~
就是一个轮子而已,最求性能的话就用yaf吧 。
我写的一个yaf的脚手架,集成的twig模板引擎,ORM等等
https://github.com/cheerzz/ya...
代码还没有看,只看了一页简介。
性能方面,一个微型框架,如果比全栈框架慢,那就见鬼了,要比就应该和Slim一类比。(定位不是微型框架)Controller变大有可能的,解决方法很多,例如Fat model、Repository等等,但是这个框架的解决方法:
直接把Controller拆了(其实就是只有一个action的Controller,实现类似Command模式),而不是考虑把逻辑封装到其他地方,简单暴力。“加载action”,也就是解析而已,连执行都不用,而且还有OPcache,所以拆成多个Action文件省不了多少时间。
翻了一下代码,有一种精简版Laravel(不是Lumen)的感觉。
其他不多说,就是不太认同第三点,不依赖其他库就性能高?自己造的轮子性能就好?能保证稳定吗?
yaf的性能好像是比较好,框架作者把微博的首屏加载时间从3秒缩到1秒。可以了解下。
不喜欢用laravel,thinkphp这些框架,感觉有点笨重吧。我现在做项目用的框架是slim(就一个路由),然后我自己封装了一个其他库(db类,Validtor类),然后就开干了
我主要用PHP开发,个人感觉,框架性能一般都不考虑,项目运营中很少(其实还没有遇到过)会因为框架效率低导致各种问题,所以选择框架,性能可以忽略。
那么那么选择框架需要注重什么?
如果是一个个人开发者,那么只考虑你用的爽不爽就好了,因为不需要考虑别人。
如果是一个team,那么需要考虑每个人的接受能力,你选择一个高大上的框架,没错是看起来很优雅,但是很多人需要花1-2月学习,是不是很浪费呢?
最后,存在即道理,每个框架存在而且有很大一部分用户群,即使有人抨击又如何,你用的爽就ok了,不必在乎别人。
对于PHP,有些问题不是框架的问题,是PHP本身设计的问题,必须采用其他语言才可以解决,没办法这是脚本语言的天然弱势。
粗略看了一下这个项目的源码和使用方式,很明显看出这个项目其实就是模仿laravel的一些功能和使用方式,项目处于开发初期,如果仅仅去学习一下其实现原理的话可以看看,不过真的项目中使用的话还是建议直接用Laravel吧。