V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
dvaknheo
V2EX  ›  PHP

[吐槽]刚读了 yii3-demo, PHP 框架是怎么把 PHP (优雅的)玩死的。

  •  1
     
  •   dvaknheo · 279 天前 · 11105 次点击
    这是一个创建于 279 天前的主题,其中的信息可能已经有所发展或是发生改变。
    虽然是看 yii3-demo 吐槽的,但 Laravel 等框架也适用。

    业务代码里,和框架相关的代码越少才是耦合性越低啊。口口声声说解耦,但是一看代码里一堆和框架代码相关的,这能叫解耦么。

    业务代码里,框架相关的代码多,意味着碰到框架相关的代码就越多

    读代码,最怕的之一是:这东西怎么来的。 一两个特例马上能教人懂,多了没法马上会啊。

    View 里不能做任何计算,不能 include 非 View 的代码。

    Laravel 优雅的带着 PHP 优雅的 Java 化。当初 PHP 上手就干的年代,这是 PHP 的优势。

    现在一堆代码,业务相关的没几行,这还是 PHP 么。

    ORM 就非用不可么,Data struct 不容易理解么

    有好用的文件路由不用,非得手写路由 (src/Factory/AppRouterFactory.php)
    PHPer 的原则应该是 其他路由模式是文件路由的补充啊。

    配置文件里一堆 use (config/web.php)

    MVC 缺层都是大家的共识了, 业务逻辑层叫 Service 或 Logic 我都无所谓,但直接 Controller 里调用 ORM,以前 10k 行的 Controller 啊。 从 Controller 里把业务逻辑剥离出来,跑命令行测试不好么。

    PHP 开发速度很快,运行速度也很快。 没必要为了那些优雅牺牲开发速度,运行速度。

    讲真,我动力再足一点,写个同功能的 插进这些框架的 demo 中, 让大家见识一下应该用什么样的手段最符合 PHP 的快速开发模式。
    126 条回复    2020-05-06 23:33:44 +08:00
    1  2  
    encro
        101
    encro   278 天前
    @HiCode

    小而美得框架也已经有一堆了啊。
    所以没必要重复造轮子。
    大框架也提供了小而美得兼容方式。

    至于 PHP 发展,我有两个观点:

    第一:

    一门想语言发展好,主要是建立好生态。

    这方面探索我们能看到的有:

    1,前面我提到可以建立一个基于云原生的框架;

    2,symfony 的 api 平台;

    3,thinkphp 的 fastadmin ;

    4,微擎的应用商店;


    第二:

    PHP 享受了 WEB 高速发展的红利期,
    而现在虽然还没有进入衰退期,
    但是 WEB 发展已经没有以前那么快了。
    前文提到环境变化了,
    恐龙就不能生存了,
    自我改良是缓慢的,
    所以不要将所有鸡蛋都放在一个篮子里面,
    我们尝试 PHP 新出路同时,
    不妨碍同时 go,python,java 甚至 c++等语言,
    生老病死本常态,
    一招鲜吃遍天的懒惰思想是行不通的。
    encro
        102
    encro   278 天前
    @nicoljiang

    PHP 还是简单,快速啊。
    你看我都学了用了这么多框架,
    我还是个很懒的人,
    经常在 v2 灌水。
    就知道这些框架有多简单了。

    你说的 lue,python 方向是可以做客户端之类的吗?
    那些真不适合 PHP 。

    我宁愿去学 C#,C++,
    每个人都有适合自己的定位。
    历史决定的。
    HiCode
        103
    HiCode   278 天前
    @encro 我很早就在准备换 lua,改用 openresty,我的业务不复杂。

    其实当我们这么聊的时候,哈哈哈哈,PHP 就只是一个选择而已。
    encro
        104
    encro   278 天前
    @HiCode

    openresty 很好,价值很大。
    曾经尝试做 waf 。

    你们网站流量居然用 openresty ?
    比我现在做的流量高吧?
    我怕人难招,老板嫌开发不够敏捷。
    如果不是因为上面原因,我更乐意用 go 慢慢堆代码吧,毕竟新玩具比较好玩。
    hantsy
        105
    hantsy   277 天前
    @meshell 只是记忆中的而已,我好久没关注 PHP 了。
    hantsy
        106
    hantsy   277 天前
    PSR 现在很多东西都是标准化,Class Loading,HTTP Messages,Mididleware,Logging,DI 等,各标准都是有大量实现。如果你真的是熟悉 PHP 生态,完全可以不用任何框架,自己像写 ExpressJS 程序那样,用一个 App 类启动组装一下,还纠结什么优雅问题。
    wwolf
        107
    wwolf   277 天前
    楼主懂不懂 php 哦,业务代码在于你业务的丰富度,口口声声在吐槽框架是什么鬼。期待你写一个我们围观一下?
    yahon
        108
    yahon   277 天前
    ROR 和 Django 不香了吗?
    Varobjs
        109
    Varobjs   277 天前
    @wwolf 楼主有框架的,可以去围观 👀
    shanghai1998
        110
    shanghai1998   277 天前
    php 天下无敌
    HiCode
        111
    HiCode   277 天前
    @encro 小项目 H5,流量是不确定的,服务器成本预算不多,所以很难。
    king888
        112
    king888   277 天前 via iPhone
    语言,框架始终只是工具,花样玩出头也就那样,都是浮云,什么业务场景适合用什么就用什么,没有就自己造,没什么好争来争去,谁也说服不了谁。
    jhdxr
        113
    jhdxr   277 天前
    @dvaknheo
    > 恕我浅薄,我真不知道依赖注入,对于动态语言,除了解决 [调用方式不变,实际实现可变] 功能之外还能有什么用。
    如果你之前不知道,不是你的错。但现在有人明确给你指出这个概念以后,还在用你自己设想的(没错你之前的帖子我也看了,这几个你一直在强调的字我也有印象)

    > 超长字符串拼接效率高还是 ob 函数分段输出效率高?
    字符串拼接效率高,有数量级上的差距。( https://3v4l.org/K7c6e

    > 我所说的热修复,就是不强行去改第三方库的代码,修复出第三方库出现的功能。
    > 就是要跟踪到第三方库还没解决问题,这才是折腾。
    『另外你这个函数能做到的,依赖注入也都行。』
    此外我觉得对于一个高级程序员,在三方库中踩坑是一个很常见的事情。。。


    @HiCode
    > 框架是一定要用的,这是生产力工具,以一定的性能损耗换取开发效率提高非常有意义。
    > 我只是因为穷才追求高性能,我的业务都是薛定谔的“qps”,爆不爆发看策划看设计,我只负责打造一个“低成本高效率”的系统。

    那么我有个疑问,像 laravel 这种被批评的,在你看来,是因为它的设计导致了性能损耗,但却没有带来开发效率的提高(设计带来的价值是负),还是尽管它带来了开发效率的提高,但是相比它带来的性能损耗,性价比太低(设计带来的价值依然是正数,但是很低)?
    如果是后者,我有一个新的疑问。我们都知道在优化时一般我们应该先优化瓶颈部分。那么框架性能是否已经成为了一个瓶颈,或者说不可忽略的因素?
    HiCode
        114
    HiCode   277 天前
    @jhdxr

    第一个疑问,“laravel 带来了开发效率的提高,但是相比它带来的性能损耗,性价比太低”——我不反对优雅,我反对的是以性能为代价的“过度”优雅,将原生 PHP 的性能降到 4%,是很恐怕的一种优雅。

    第二个问题,对于我日常的项目来说,有 redis 后,php 的性能问题就变成了新瓶颈,有钱可以直接升级服务器,没钱就要想办法抠性能。

    我觉得我最重要的观点就是:土豪请随意,没钱才焦虑。
    JokeEnd
        115
    JokeEnd   277 天前
    大概看了 Lz 框架一眼,可能是正统的 tp3 受害者吧

    类似 App::G 这种东西,建议就别用了,跟 tp3 那年代一个函数用 ABCDE 命名那种差不多,不明所以,点进去人都懵了,一点也不清真

    每次接手年代久远的 php 项目,那些代码基本不是给人看的,只能当场重写·
    james122333
        116
    james122333   277 天前 via Android
    opcache fastcgi 大家都会用
    主要为何要全依赖框架 有时候需要的功能只要稍微改改底层实现就可以了 而不是叠床架屋
    硬拼个能够符合全部需求的
    装一堆插件的 vim 启动好几秒 自己写的秒开 也是一种例子
    太重的东西个人觉得不是优雅
    zencoding
        117
    zencoding   277 天前
    dvaknheo
        118
    dvaknheo   277 天前
    @JokeEnd
    App::G 又不是给写业务代码的用的,业务代码的人,一般只会在 Controller, Service,Model,View, 这四个目录。对应的 ControllerHelper,ServiceHelper,ModelHelper,ViewHelper 里有什么东西才值得看。 这些 Helper 的 GetExtendStaticMethodList() 有点恶心而已。

    G 方法用于扩展的。 比如你要替换默认的实现。

    @zencoding

    奇怪,怎么不从主流程看起呢? RouteHookRewrite 这个扩展默认没加载,而且我文档都没写完啊。
    如果你从代码琢磨起。 最古怪的是怎么 DuckPhp\App 初始化后跑的是 MY\Base\App 的代码。这部分需要在 init 函数里琢磨一下。

    DuckPhp\Core\App use DuckPhp\Core\Kernel->init ,run 才是核心, 还有个复杂的是 DuckPhp\Core\Route 路由。

    @jhdxr
    字符串拼接效率高,有数量级上的差距。
    谢谢,我之前没估计过。,但 View 还是基本上以 echo 方式显示的,基本没见到 heredoc 类型的。如果追求效率,看来还是把 view 文件转为 heredoc 模式的文件好,综合起来,这为方便牺牲效率,这可以接受。
    jinsongzhao
        119
    jinsongzhao   277 天前
    这 Yii3 是什么来头?熟悉的 Yii 和 Yii2 原作者都不见了
    dvaknheo
        120
    dvaknheo   277 天前
    额,我自己失误了,G() 函数确实会在业务中用到。如果为了扩展性。
    XService::G()->foo 和 XModel::G()->foo 这种用法经常有。
    或许实践起来会有一排,改成 static function 调用 吧,就是
    XService::foo(); 和 XModel::foo();

    有一种情况是 XSerivce::G 这模式省不了, 没默认载入的扩展,JsonRpcExt 切换成远过程调用。这属于高级用法了,具体在相关 ref 里
    Varobjs
        121
    Varobjs   277 天前 via Android
    看样子 G 函数是 getInstance 获取单例之类的
    话说现在不应该人均 IDE 写代码了吗,G 还得按 shift,还不如 getInstace,偷鸡不成蚀把米的感觉
    conn4575
        122
    conn4575   277 天前 via Android
    php 的问题就是框架太多,没有像 spring 一样的集大成者,开发者资源都浪费在发明框架重复造轮子上面,现在是后互联网时代了,生态够广才能活下去
    cszchen
        123
    cszchen   277 天前 via Android
    @conn4575 并不会,大部分造轮子的都是自嗨
    yekern
        124
    yekern   277 天前
    ... 不喷不闹 推荐大家去看看郭德纲的 《你要高雅》
    dvaknheo
        125
    dvaknheo   263 天前
    我 fork 了一个 yii3 demo 的版本(大概 80%进度),在 入口处 加了些代码,强行插入 duckphp 框架版本的实现。见

    https://github.com/dvaknheo/yii-demo

    我切 github 默认分支不是 master 分支,而是 for_duckphp 分支。

    for_duckphp 分支,实际干了两个分支的事情,后面再拆分。

    for_duckphp 另一个分支功能的事情 是 service 化。src/service 目录 ,抽出来,单独成立一个分支,然后画关系图让大家看看 这部分和 duckphp 没关系

    最主要的就是在 index.php 入口 插入 duckphp 版本的实现。
    duckphp 版本的特点

    1. 只在 composer.json 依赖一个包:dvaknheo/duckphp 1.2.3 。
    2. 相关实现都在 app 目录底下。其他文件只改了 public/index.php ,src/Command 目录的命令行入口。
    3. 保证输出和 yii3 demo 一致。原有 bug 不改。入口文件在请求完之后 curl 原来 url,如果相同输出,则输出 same. 否则输出 different 并在 runtime 里加 a.php ,b.php 方便对比。
    4. 业务逻辑提取成 Service 层 . 6 个目录,view 是视图目录,config 是配置目录, Model 跟着 表走,Controller 负责输入,输出 view 前处理,业务放到 Service 。 Base 目录是核心才动的目录。基本上不交叉引用。

    用 cloc 算了一下 app 目录 1760 行,比 src 目录 2289 行少点, 还有点 yii 的引用,主要是 3 个复杂组件没拆解,也不想拆解,留着就行。 分页还有进一步调整可能。

    两个星期折腾这个代码,感觉有点慢。 或许,就弄了个大白象?
    回头来看 yii2 的代码主要还是 卡在 behaviors 和 actions 上, 说不定哪天就重写了。 然后把 gii 也重写了。

    到现在,逆行工程,主要还是,这玩意从哪里来的? 这玩意被什么东西悄悄调用? 这玩意里面有什么?

    yii3 里 那个 widget PostCard 在 view 里计算 我就很不爽, 后面拆解成 view 文件 ,传入 array 。看上去清晰多了。

    还有想吐槽的暂时记不清,就暂时到这吧。
    ajaxfunction
        126
    ajaxfunction   256 天前
    说实话 php 适合小作坊类, 甲方要求 3 天一个 H5 项目(投票,抽奖,砸金蛋,猜灯谜,划龙舟等) ,从 0 到上线,费用预算 2K 。 你做还是不做?
    肯定做啊,模板切图 tp+jquery 一把梭,2 天赶项目,还有 1 天时间摸鱼

    什么 laravel 什么 vue 统统滚犊子,等脚手架搭建好,路由规则写好,活动早就结束了

    你说让 java 和 python go 程序员去写这类项目? 2k 预算,估计早就被喷出翔了吧
    1  2  
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4895 人在线   最高记录 5430   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 03:52 · PVG 11:52 · LAX 19:52 · JFK 22:52
    ♥ Do have faith in what you're doing.