探讨下对php(或其他语言)的框架的一个想法

梅开源 发布于 2017/01/23 15:43
阅读 496
收藏 1

开发时的需求和上线时的需求是不同的,但是为什么要用一套框架?

开发时希望框架工具多,代码简单。 上线时希望性能好耐操。然而要性能好耐操,基本上就要将多种复杂性抽象统一,即会大量应用对象和函数,牺牲性能。所以这种矛盾,导致很多框架太重或太轻。

有没有这样一种框架,开发时使用一套机制便于开发,确定了开发内容以后,将开发内容“编译优化”成性能较高的另一套机制?

 

 

加载中
1
卖萌的程序猿
卖萌的程序猿

其实你可以尝试soa方面的框架,基本就可以满足你现在的需求,优秀的构架有一方面就是可以在不改变业务的前提下通过加机器来解决性能问题,也就是所说的集群,如果业务过于复杂了,同样也可以通过这个框架来解耦,也就是常说的分布式,PHP这个方面的框架比较少,Java的比较多,比如很火的Hadoop,SOA服务治理方面的有阿里的dubbo,微博的motan,spring的spring cloud,就是常听说的微服务架构,其实他们做的就是在应用层上基本实现了网络和计算机了那些概念,比如注册中心就是相当于dns,网络就相当于计算机里内存硬盘的IO,PHP的思想主要还是在单机上的局部性的,所以PHP的领域就是CURD以及偏前端的逻辑,语言只是工具,框架只是别人的规则,主要学编程思想和基础知识

1
宇润
宇润

你尝试自己开发框架就会知道,很多地方不能两全,肯定要有牺牲……

比如你要把一个东西做的简单,然后还要做的灵活,这就是有冲突了。做灵活肯定会有很多可变的地方,可变地方一多,用户或其它开发者就感觉不简单了。

0
乌龟壳
乌龟壳

抽象程度对性能的负面作用,在java/c++等静态语言中不会有python/php等动态语言那么明显。静态语言有有多种优化能把抽象还原成纯粹的计算逻辑。

https://www.zhihu.com/question/50606200

0
卖萌的程序猿
卖萌的程序猿
心中有编程思想,写出来的处处都是框架,用别人的框架主要是为了低水平的程序员使用的
卖萌的程序猿
卖萌的程序猿
低水平是相对概念,不要理解的太偏激
y
ylmotol7
这说的就有点扯淡了,难道阿里里面全部都是低水平的?阿里不同样是使用了框架,这装的有点过了
0
eechen
eechen


php-src/Zend/bench.php测试中,7.1相比7.0有26%的性能提升.
php-src/Zend/bench.php测试中,PHP JIT速度是PHP 5.4的10倍.

看看PHP7开启JIT支持下bench.php计算性能的测试对比. 可以看到,涉及到PHP最常用的hash关联数组的循环测试时,Zend-JIT的效果并不明显. Resin(JVM)的Quercus,DotNet的Phalanger甚至比没有JIT的PHP-5.6还要慢几倍.所以说,要高性能,直接上PHP7就好了,opcache会把你所有的脚本编译成opcode后缓存在内存,根本不需要折腾那些第三方的PHP实现.而且就算是最好的第三方实现,也是经过非死不可生产线检验的HHVM,根本轮不到基于JVM的Quercus.

我觉得,对PHP这门语言的Web运行模式来看,大型PHP框架是不适合PHP的.PHP之父Rasmus Lerdorf(拉斯马斯·乐多夫)不看好复杂的PHP框架,在PHP之父看来,PHP框架并不符合PHP的设计哲学,框架拉低了性能,增加了复杂度.

Rasmus Lerdorf opinion on PHP frameworks: "They all suck!"
https://www.phpclasses.org/blog/post/226-4-Reasons-Why-All-PHP-Frameworks-Suck.html
http://www.youtube.com/watch?v=anr7DQnMMs0 (PHP Frameworks Day 2013)
Rasmus Lerdorf, the PHP creator, was invited to give a talk in PHP Frameworks Day 2013 conference.
He talked mostly about the latest PHP developments,
but in the question and answers section,
somebody asked Rasmus about his opinion on the PHP frameworks.
That was as straight question about his opinion,
so Rasmus gave a straight answer (near 31m 47s): "They (PHP frameworks) All suck!"
Resaons:
1. Frameworks Execute The Same Code Repeatedly Without Need (框架重复执行了相同代码,这是不必要的)
2. Frameworks Require Too Many Interdependent Classes (框架需要太多相互依赖的类)
3. Needlessly Complicated Solutions (不必要的复杂的解决方案)
4. Duplicating the Web Server Functionality (重复实现了Web服务器本来就支持的功能,如前端控制器模式)
So, are there any frameworks that don't suck?
Rasmus did mention that he liked CodeIgniter
because it is faster, lighter and 【the least like】(最不像) a framework.

鉴于重型框架不适合PHP每次请求释放资源的FastCGI运行模式, 所以DHH当时作为一个PHP开发者,并没有选择在PHP上实现Rails.

早在编写PHP程序时DHH就开发过一套框架,目的是使PHP能在项目中变得简洁快速, 将程序的界面、控制和数据分离开来,方便团队间的协作和维护。  Basecamp项目之初,DHH试图使用自己的PHP框架进行Basecamp的开发,但没过几天DHH就发现了一些问题:  PHP每次HTTP请求都要初始化资源,这个过程的开销非常大。  尽管PHP解析器的运行速度快速且没有缺陷, 但一旦使用框架, 那么每次请求时初始化整个框架使性能的下降非常厉害,  当使用一个很复杂的PHP框架的结果就是整体性能严重下降;  同时,PHP语言本身的问题造成了PHP添加跨请求的高级特性相当困难, 这是PHP本身一个很大的限制, 但是反过来说,正是这种限制使得PHP始终保持在一个比较简单的Web语言上面,  而正是这一点才是PHP得以成为互联网流行Web编程语言的原因。

鸟哥同样也不看好复杂缓慢的PHP框架.

图灵访谈问:
你是在什么样的契机下开发了 Yaf?当时百度是如何支持 Yaf 开发的?
PHP鸟哥答:
应该是在 2011 年吧,那个时候为百度开发了 Ap(Yaf 的前身项目), 当时在百度内部用的还不错,于是我想着要贡献到 PECL 上去, 修改了一些以后,改名为 Yaf(Yet another framework,这个名字也是有点自嘲的意思,因为 PHP 的框架非常多),就发邮件到 PHP 的邮件组, 因为英语比较烂,所以过程还是比较曲折,好在当时 Pierre Joye 帮助我了很多,让 Yaf 进入了 PECL。 在 Yaf 之前,关于使用不使用框架其实一直有一个经典的争论就是: “使用框架会降低性能,而不使用框架会降低开发效率。” 当时百度内部的框架很多,包括开源的 Yii,ZF 之类的,也包括有的团队自己写的。 这样有一个问题就是类库,一些周边设施没有办法互通。 还有一个原因就是,很多框架作者把框架发布出去以后,会发现不同的人会对框架做各种修改, 导致时间久了,一个框架发出去,就变成了各种变种,后续统一升级也变得不可能。 所以,我决定要用 PHP 扩展实现一个框架来解决这些问题, 当然在写这个扩展之前其实也不是很有信心, 不知道采用扩展能带来多大的性能提升。 好在最后的结果是很好的。

鸟哥还说过:
PHP 确实简单,这也是我们追求的目标,我们希望它简单,简单难道不好吗? 可能有些人会寄希望通过一些复杂的东西来体现自己的优越感,这其实也没什么问题。 只是我个人不认可这种态度,我觉得什么简单就用什么呗。 回过头来说,你说 PHP 简单吧它也不简单,PHP 相关的东西现在也有很多,比如一些很优雅的框架。 有些框架我自己看半天也会觉得还挺复杂的,学起来费劲。 我自己是用 C,我就是喜欢用简单的东西,我不太喜欢那种特别复杂的东西,因为要去理解它。 之前我跟别人好像有过一次争吵,他的意思是说你只要肯学一定能学会,学不会说明你有问题。 对我来说,我会去学也会去看别人的东西,但是用起来一定是用我最顺手的东西去解决问题。

总而言之,结合牛人的观点和自己的实践,我的感悟就是大型框架并不适合PHP,因为PHP的Web运行方式跟其他语言大相径庭,差异很大,照搬其他语言的方法过来肯定是得不偿失的.要想获得高性能,就得结合PHP的运行模式来指导开发.下面具体说说我的做法:

1.PHP本来就具有模板语言的功能,所以根本没有必要引入一个第三方模板引擎来拉低性能和增加学习使用成本.

2.PHP的运行模式如Apache模块或者PHP-FPM,本质上是一种CGI模式,URI可以直接对应到服务器的文件目录,所以我认为根本不需要"前端控制器"来统一入口进行路由.一个PHP文件其实就可以作为一个"页面控制器".每个页面控制器define定义一个常量APP_ROOT用来标记入口如,不是页面控制器的文件通过判断该常量是否存在来判断是否是正常访问,没有定义该常量则直接退出程序.

3.高性能无损耗的页面控制器已经确定下来了,分离界面和逻辑就能轻松实现MVC,避免界面和逻辑混在一起.要分离视图view和页面控制器controller,只需一个简单的render函数,实现起来相当简单:
function render($template) {
    ob_start();
    require $template;
    return ob_get_clean();
}
页面控制器如/post.php只需这样:

<?php
if(!defined('APP_ROOT')) define('APP_ROOT', dirname(__FILE__));
require APP_ROOT.'/include/common.php';
$app['data'] = get_post_by_id($_GET['id']);
$view = render('post.php');
echo $view;
?>
这样就好了,render函数定义在functions.php里,common.php里包含了配置config.php和库函数functions.php,相当清晰.因为$app是config.php里定义的一个全局关联数组,就像Windows的注册表,任何数据都可以存到这个数组里,包括数据库操作结果等等,面向数据编程(程序的本质就是输入输出),functions.php里定义的函数可以理解为一道道工序,在控制器中写好逻辑得到结果后放回$app,视图里的可以直接从$app里拿到数据组织HTML返回,有时并不需要渲染HTML视图,这时控制器直接json_encode相应数据后直接输出即可.

4.上面说了控制器和视图,那模型呢?其实全局数组$app就是程序最核心的数据结构和模型,小的模型都保存在$app里,比如当前用户数据$app['user'],设计模型就变成了设计数组,模型数组的操作就变成了定义在functions.php里的工序.对于新手而言,打印$app看看结构,打开functions.php看看函数,就能知道个大概并快速融入开发.而且用一个文件functions.php组织函数的方式也非常方便使用文本编辑器的开发者,因为程序具有的功能一目了然.可能有人会说,一股脑加载所有函数定义会影响性能,但我只想说,函数定义这点开销真的微不足道,带来的便利却显而易见.

5.问题越复杂,处理问题的逻辑肯定也会跟着复杂,不会因为你用了XXX写法就会变得简单,不过可以把问题分解,让其更清晰更好维护.比如你有一个settings页面控制器,用于设置很多东西,有很多表单要处理,比如可以这样分解:
/admin/settings.php?section=setup
/admin/settings.php?section=features
分解成:
/admin/settings/setup.php
/admin/settings/features.php
这样,就算再多section也不怕,统统分到settings下面,而且看文件目录就能识别从属关系.settings的子控制器如setup.php里有多个表单的话可以用switch($_POST['action'])处理,如果觉得复杂冗长,还可以再细分出来:
/admin/settings/setup/a.php
/admin/settings/setup/b.php
对应的视图也采用一样的从属关系:
/admin/view/settings/header.php
/admin/view/settings/setup/a.php
/admin/view/settings/setup/b.php
/admin/view/settings/features.php
/admin/view/settings/footer.php

PHP高性能和快速开发就是这么来的,让那些PHP框架见鬼去吧,简单和高性能才是王道.

yak
yak
https://www.oschina.net/question/123890_2188383 脑残张嘴就来慢几倍,把你慢几倍的代码掏出来看看
yak
yak
脑残你复制粘贴这么多,你做的网站呢?掏出一个来看看 复制粘贴你也要找对地方, 赶紧来这里复制粘贴,保证不打死你 https://laravel-china.org/topics/3583
乌龟壳
乌龟壳
对于合格的php开发人员来说,应该每个人都能做出最适合自己的框架,php这么高层次的封装,自己做框架足够简单。但是这里有一个地方要澄清的,同一个项目组应该统一框架,不能各自用自己的。
eechen
eechen
回复 @乌龟壳 : 也就是说你也不赞成PHP开发使用框架.
乌龟壳
乌龟壳
java之所以必须框架是因为java标准库对web支持太少了,就像c一样,如果不做一个框架(如php),开发起来太慢。
下一页
返回顶部
顶部