这个库代码几分

[theswow]

https://github.com/Jetea/ctx
求大佬们指导

[knva]

100 分怕你骄傲
给个 99 吧

[jfcherng]

Pimple 有工廠單例、懶加載，這個庫相對 Pimple 的優勢是什麼呢？
https://github.com/silexphp/Pimple#defining-factory-services

[zn]

Pimple 了解一下。

[ipwx]

为啥你模块化的这个思路这么像 python。

讲道理，把一个语言的思路直接搬到另一个语言，一般是不好用的。

[theswow]

@zn 这个还真了解过，slimphp 里边貌似就用了，我看过大量的出名和不出名的框架源码的

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

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

各个项目就是入口，应对不同的场景，负责获取输入和响应输出，比如 api 是 json 输出，鉴权可能也不同，web 可能是输出页面或则开放平台暴露给第三方那么输入获取方式又不一样，命令行脚本项目呢，则获取输入又不同，也没啥鉴权。
但是这些项目最后逻辑都不自己实现，通过引入 ctx 入口并调用 ctx 中各个模块的方法来。也就是 ctx 是一个独立的版本库，然后发布的时候发布到了其他需要引入的项目中。

[theswow]

@ipwx 我是从之前工作的公司他们的思路中提取出来的这个，是为了方便在 一个团队中协作的时候，大家按照统一的方式来规范模块，模块的代码按照什么方式来组织，放哪个文件夹，调用的时候又是怎么个统一的方式进行模块之间和模块内部子模块之间的调用，而且为了方便部分模块的优化和部分代码的保密（比如加密算法），提供了一种简单的 rpc 实现，同时对外部调用透明化，对外调用方只需要知道有啥对外接口，输入参数是多少，输出的返回值是什么样就可以了。

[jfcherng]

聽你說完，感覺像個帶了路由功能的 Pimple...

[theswow]

@jfcherng 哈哈，差不多，就是模块之间组织和调用。

[zn]

@sh7ning 你这个在项目比较简单的情况下可能还算好用，如果项目复杂一点，模块间互相依赖一多，模块之间互相调用就像蜘蛛网一样，牵一发而动全身，时间一长，后来的维护者动都不敢动，很蛋疼。

可是如果项目很简单的话，貌似也不需要分什么模块了呢………

[ipwx]

@zn 我没用过 PHP，不太清楚你们搞这一套会有什么坑。

Python 的模块化其实……还好，因为有一套范式。而且 Python 可以在函数内部局部 import。如果遇到循环 import，语义也是标准化的，所以大家也都知道怎么处理。反而是 PHP、Java 里面的什么“依赖注入”，在 Python 里面是见不到的，因为那样写不 Pythonic。

[zn]

@ipwx 各有所好吧，我就很不喜欢蟒蛇的语法，感觉头重脚轻。

[hubahuba]

挺好的

[theswow]

@zn 这个是之前工作过的两家目前国内还算知名的互联网公司的思路中提取出来的代码，他们有类似这样的模块代码组织框架，其中一家公司 06 年就开始了，所以代码量复杂点的问题不大。

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

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

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


一下子说的有点多，也有点乱，🤣