首页   注册   登录
 sh7ning 最近的时间轴更新

sh7ning

V2EX 第 328221 号会员,加入于 2018-07-10 16:20:06 +08:00
今日活跃度排名 23378
2019 年全新(写)的 PHP 框架
PHP  •  sh7ning  •  9 天前  •  最后回复来自 sh7ning
13
这个库代码几分
PHP  •  sh7ning  •  22 天前  •  最后回复来自 sh7ning
13
模块化服务上下文框架 Ctx
PHP  •  sh7ning  •  23 天前  •  最后回复来自 sh7ning
1
Gopusher 一个通用的长连接服务
程序员  •  sh7ning  •  224 天前  •  最后回复来自 sh7ning
1
sh7ning 最近回复了
9 天前
回复了 sh7ning 创建的主题 PHP 2019 年全新(写)的 PHP 框架
刚看到 https://github.com/laravel/framework/pull/26898 Laravel 也要开始移除全局方法了

很多的框架都有各种全局的变量,常量(define),函数,没在命名空间下定义,虽然有 function_exists 来判断后定义,但是会带来的问题是增加了开发人员的心理负担,比如定义了同名的,但是作用不同,那可能改变了很多。

框架作为底层,要减少应用开发人员的使用成本,减少黑魔法也很重要,也方便开发人员统一书写,比如 laravel 中很多时候,一个团队对一个请求参数的获取有好几种写法,我觉得这些地方就增加维护成本,虽然见多了就知道了,但是搜索替换的时候~
9 天前
回复了 sh7ning 创建的主题 PHP 2019 年全新(写)的 PHP 框架
@ericgui 我就是觉得那些都设计复杂了,就想着搞个精简的只提供必需的,代码简练点的框架
21 天前
回复了 sh7ning 创建的主题 PHP 2019 年全新(写)的 PHP 框架
@xiaotuzi 没咋个明白,我觉得已经够简单了吧,那咋个更简单了,比如?

@conn4575 这个其实是写着玩的,另外就是开源的框架中我喜欢 laravel 的代码,但是不喜欢 laravel 那种包都是依赖他自身生态的,我更喜欢 sf 框架那种组件化,每个包尽量少的依赖那种,所以会看到 sf 的包被大量的其他框架所引用,另外就是 lara 的代码写的比较绕

所以我就结合 n 多框架的实现,其中大量参考 laravel 的实现,简化提高可读性,另外就是减少依赖,当练手。

其实我建议新人都写一个自己的框架,练手也好,提高基础也好,这样会更能理解一个框架的运行原理,也更知道怎样的代码怎么写出来是具有可读性,可维护性,可扩展性特别是框架层面,在用其他框架的时候也会更加得心应手,很多时候以为框架很简单,但是只有自己去实现过一个后就觉得不是啥都是看起来那么理所当然,里边可能一个细节都是有思考的。

比如你写了框架你就知道用 composer 的好处不只是方便引入其他的包,对于框架还有个好处是,不让应用开发者随意更改框架核心代码(以后不便于升级或则框架 bug 修复啥的),但是为了在允许开发者自定义的地方要支持可扩展性,所以其实这些过程中的思考都能提高编码水平。

再比如,对异常的理解,如果吧 php 的异常和错误处理了解好了,就可以写出更好的代码,而不是通过 true false 之类,好多框架在这块的处理也不是很合适,比如错误发生的情况有的喜欢直接屏蔽,有的是直接 handle 处理了,其实更好的方式是转换为异常,这样写业务的时候,就算错误,你可以选择 catch,也可以不 catch 走全局的异常接管。这也是为啥不要直接裸写 php,框架其实对这些都做了处理可以减少新手犯错的可能,异常处理可以参考 laravel 和 yii 他们的处理方式,当然也可以参考我这里的一个包实现,https://github.com/Jetea/exception
22 天前
回复了 sh7ning 创建的主题 PHP 这个库代码几分
@zn 这个是之前工作过的两家目前国内还算知名的互联网公司的思路中提取出来的代码,他们有类似这样的模块代码组织框架,其中一家公司 06 年就开始了,所以代码量复杂点的问题不大。

想象一下,如果大家用同一种方式来写逻辑代码和复用代码,而不是放到控制器中,是放到一个可以共用给 web,命令行脚本,第三方开放 api,移动端 api,admin 后台等多个不同的项目的公共逻辑代码库中,提高了复用性,

为啥不用微服务来复用,因为小公司来说,不用那么复杂的调用和部署维护,虽然 rpc 调用也简单,但是 http 还是有开销,特别是对于 php 这种每次请求都要从框架第一步开始。同是 ctx 也提供了 rpc 的可能用于在部分业务需要单独部署优化的时候。所以 ctx 这种代码共用到其他项目中,直接引入 require 的方式性能更好。

另外就是 ctx 是只要保证模块对外的方法输入参数和返回值不变,那么其他模块的开发者只需要关心自己模块的实现就行了,所以经过 n 多年后,就算新入职的同事,参与模块开发的时候只需要了解自己模块就行了,其他模块逻辑和其他模块的数据库根本不用关心。


一下子说的有点多,也有点乱,🤣
23 天前
回复了 sh7ning 创建的主题 PHP 这个库代码几分
@jfcherng 哈哈,差不多,就是模块之间组织和调用。
23 天前
回复了 sh7ning 创建的主题 PHP 这个库代码几分
@ipwx 我是从之前工作的公司他们的思路中提取出来的这个,是为了方便在 一个团队中协作的时候,大家按照统一的方式来规范模块,模块的代码按照什么方式来组织,放哪个文件夹,调用的时候又是怎么个统一的方式进行模块之间和模块内部子模块之间的调用,而且为了方便部分模块的优化和部分代码的保密(比如加密算法),提供了一种简单的 rpc 实现,同时对外部调用透明化,对外调用方只需要知道有啥对外接口,输入参数是多少,输出的返回值是什么样就可以了。
23 天前
回复了 sh7ning 创建的主题 PHP 模块化服务上下文框架 Ctx
链接已经切换到了 https://github.com/Jetea/ctx
23 天前
回复了 sh7ning 创建的主题 PHP 这个库代码几分
@zn 这个还真了解过,slimphp 里边貌似就用了,我看过大量的出名和不出名的框架源码的

我这个跟他们作用不同,不是依赖注入,是一个模块化的框架吧,组织代码的,比如里边 rpc 调用跟不采用 rpc 对于调用方来说无感知,这样模块开发者只需要保证模块的方法的输入输出不变化,内部随意切换 rpc 实现

另外就是整个逻辑代码都由 ctx 来组织后,可以共用给多个项目,只需要在项目中引入 ctx 入口就行了。

各个项目就是入口,应对不同的场景,负责获取输入和响应输出,比如 api 是 json 输出,鉴权可能也不同,web 可能是输出页面或则开放平台暴露给第三方那么输入获取方式又不一样,命令行脚本项目呢,则获取输入又不同,也没啥鉴权。
但是这些项目最后逻辑都不自己实现,通过引入 ctx 入口并调用 ctx 中各个模块的方法来。也就是 ctx 是一个独立的版本库,然后发布的时候发布到了其他需要引入的项目中。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   804 人在线   最高记录 4385   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 12ms · UTC 22:43 · PVG 06:43 · LAX 14:43 · JFK 17:43
♥ Do have faith in what you're doing.
沪ICP备16043287号-1