希望框架能更完善的几个点

[zeroxxmmbm]

使用了swoft与hyperf 的一些感觉，是比较喜欢hyperf的，文档比较好，纯属个人建议，也有些地方用起来觉得很麻烦的，也可能是我不够了解这框架。比如相比之下少了@bean注解没有那么方便，各种要去配置文件配置，自定义注解收集与解析用起来也感觉比较麻烦；swoft的Entity层是个人比较喜欢的，弱类型语言导致我们都要面相数据库工具开发，有了实体层与数据库字段的映射方便程序员开发时候不用一直去看数据库，找到实体层，实体层可以定义关联注解，类似spring，那是比较完美的，swoft缺陷没办法定义模型关联。框架启动做的很粗糙， 没有重启 停止功能。没有一些内置的公共函数，有时候用起公共函数还是比较舒服的，就比如context()通过上下文直接获取一个response对象特别方便。希望下个版本可以更完善吧。

[limingxinleo]

Bean注解，确实打算加一个，不过不叫做Bean

另外 context方法，自己封装一个就行了

[limingxinleo]

启动，只提供了 start 是有意为之的，这个也不会改的

[mogody]

@limingxinleo 还有就是建议可以完善一下微服务相关的组件，可以对标java的spring cloud；比如grpc协议可以支持注册中心，甚至可以把注册中心、配置中心等等这些组件都抽象成接口，官方提供一些默认的驱动以及驱动开发文档，然后开发者可以自己开发新的驱动

[zeroxxmmbm]

@limingxinleo 提start是因为我用的虚拟机与docker,停止后重新进去进程在但是没法ctrl+c，进去后原来用户丢失了 每次都要找到master进程id手动给信号kill掉，没有一个stop指令所以会感觉麻烦，但总体不影响。
因为之前用.netcore开发，回归PHP框架开发，目前还没找到在模型实体方面设计很好的框架，合作开发时确认字段都要翻一遍数据库。

[OverNaive]

@zeroxxmmbm 建议使用 supervisor 来守护进程。

[lishuncoder]

@limingxinleo 提start是因为我用的虚拟机与docker,停止后重新进去进程在但是没法ctrl+c，进去后原来用户丢失了 每次都要找到master进程id手动给信号kill掉，没有一个stop指令所以会感觉麻烦，但总体不影响。
因为之前用.netcore开发，回归PHP框架开发，目前还没找到在模型实体方面设计很好的框架，合作开发时确认字段都要翻一遍数据库。

你也遇到了一样的问题，我也是很奇怪为什么只有start没有stop，导致我start守护之后，只能读取pid去kill，怪麻烦的

[huangzhhui]

在我看来，里面提到的很多观点是还没理解清楚 Hyperf 的设计理念和相关机制 ，而用其它框架的设计理念套用过来所产生的

比如相比之下少了@bean注解没有那么方便，各种要去配置文件配置，自定义注解收集与解析用起来也感觉比较麻烦

这句话提到了3点，首先 @Bean 注解的问题，Bean 仅仅是为了定义给 Inject/Autowire 注解所出现的产物，而在 Hyperf 里的理念是所有类都应该设计成可持久化被注入的，故不存在所谓的 Bean 概念，那剩余的你指的可能是 @Bean(scope="prototype") 的多例场景，这个在一开始设计时是不希望存在的，可以通过 Context 协程上下文代理的形式解决每个类，具体做法可参考 Hyperf\Utils\Traits\StaticInstance，当然也不排除后续会通过注解提供类似的做法；
其次配置这里我理解你所说的应该是两个说法，一是 config/autoload/dependencies.php 配置依赖注入关系，这个是必须存在的，二是 Spring 中通过 @Configuration 注解来替代配置文件的存在，这我认为只不过是为了 OOP 而 OOP，为了注解而注解的做法，在 PHP 中对象配置文件的做法远比不上 PHP 数组配置的灵活性；
最后所提到的自定义注解收集和解析起来使用比较麻烦这点，在 Hyperf 里相比其他框架是简化了注解收集流程的，简化了解析器和收集器的概念，由注解类自身实现自收集，对于注解元数据的使用，实际上是对一个 PHP 数组的使用，这里的简便与否就因人而异了，不过在我看来的确也还有优化的空间；

swoft的Entity层是个人比较喜欢的，弱类型语言导致我们都要面相数据库工具开发，有了实体层与数据库字段的映射方便程序员开发时候不用一直去看数据库，找到实体层，实体层可以定义关联注解，类似spring，那是比较完美的，swoft缺陷没办法定义模型关联

Hyperf 使用的 ORM 是基于 Eloquent 的协程化修改版本，除了不像 Doctrine 那样通过注解定义 Entity，其余你所说的都是有的；

框架启动做的很粗糙， 没有重启 停止功能

这样的设计也是有意而为，不然从 Hyperf 1.0 到现在都迭代了一百多个版本了，PR 也接收到了好几个与此有关的，那为什么不加呢？
在实际运行过程中，合理的做法只有两种，一是通过启动命令直接运行前台程序，这种做法一般只作用于开发阶段，因为开发阶段需要查看代码的报错信息，而 cli 和 fpm 对报错内容的显示是不一样的，fpm 下会通过浏览器输出或写入到 fpm 的日志文件中，而 cli 下，你只需要看前台程序的 stdout 内容输出即可，如果也将错误内容通过 HTTP Server 发送到浏览器的话，会导致启动阶段的报错看不到；二是通过 Supervisor 或 Docker/Kubernetes 等工具来运行一个前台程序实例（是的，这种方式需要的也是前台程序），这种做法一般作用于生产阶段，当然也可能会使用 Docker 作为开发阶段的运行环境，这里所提到的方式都是前台程序，那后台运行只会存在于一些不合理的使用方式下，故 stop 和 restart 命令也只会作用于不合理的使用方式下，不默认提供这些命令能使用户更容易以合理的方式来使用，如用户真的有需要使用后台程序运行，通过 pid 和信号命令也可很简单的实现相关功能；

没有一些内置的公共函数，有时候用起公共函数还是比较舒服的，就比如context()通过上下文直接获取一个response对象特别方便

这个也是有意不提供的，因为这种使用方式是错误的，从 Context 中取对象是一种非常奇怪的做法（当然实际上会储存对象），如果是这样的话，那用户要如何区分什么时候从 Context 获取对象，什么时候从 依赖注入容器 Container 获取对象呢？故所有的对象获取都应该是从 依赖注入容器 Container 获取，获取到的对象内部可再根据自己的需求从 Context 获取来提供代理对象（参考 StaticInstance），所以你会发现在 Hyperf 里获取 Request/Response 对象也是通过 依赖注入容器 Container 来获取的，框架会自动区分不同协程下的对象区分；
那关于公共函数又会导致什么问题呢？不会导致什么问题，提供更多的 Function 非常的简单，但会让代码的可替代性变差，所以控制 Function 的数量是一件很难的事情，Hyperf 的关于组件设计理念是 可替换 与 可复用 的，那如果类实现和方法调用都是基于依赖注入来实现的话，再配合 AOP，这一切都能完美的实现，通过 Function 来实现方法调用的话，Function 的内容是无法被替换和重写的，因为在 PHP 中没有办法实现对一个 Function 方法的重载，故减少或不使用 Function 是一种更合理的做法；

[pro911]

黄老师讲的细,

[zeroxxmmbm]

@huangzhhui 感谢大佬这么详细的解答，我好好整理跟了解一下，谢谢。

[lishuncoder]

感谢大佬如此详细的解答，关于我start/stop的点确实是从其余框架来的，嗯 大佬说的都还是很有道理，感谢分享。

…

------------------ 原始邮件 ------------------ 发件人: "hyperf/hyperf" ***@***.***>; 发送时间: 2021年5月7日(星期五) 上午10:02 ***@***.***>; ***@***.******@***.***>; 主题: Re: [hyperf/hyperf] 希望框架能更完善的几个点 (#3539) 在我看来，里面提到的很多观点是还没理解清楚 Hyperf 的设计理念和相关机制 ，而用其它框架的设计理念套用过来所产生的 ***@***.***注解没有那么方便，各种要去配置文件配置，自定义注解收集与解析用起来也感觉比较麻烦 这句话提到了3点，首先 @bean 注解的问题，Bean 仅仅是为了定义给 Inject/Autowire 注解所出现的产物，而在 Hyperf 里的理念是所有类都应该设计成可持久化被注入的，故不存在所谓的 Bean 概念，那剩余的你指的可能是 @bean(scope="prototype") 的多例场景，这个在一开始设计时是不希望存在的，可以通过 Context 协程上下文代理的形式解决每个类，具体做法可参考 Hyperf\Utils\Traits\StaticInstance，当然也不排除后续会通过注解提供类似的做法； 其次配置这里我理解你所说的应该是两个说法，一是 config/autoload/dependencies.php 配置依赖注入关系，这个是必须存在的，二是 Spring 中通过 @configuration 注解来替代配置文件的存在，这我认为只不过是为了 OOP 而 OOP，为了注解而注解的做法，在 PHP 中对象配置文件的做法远比不上 PHP 数组配置的灵活性； 最后所提到的自定义注解收集和解析起来使用比较麻烦这点，在 Hyperf 里相比其他框架是简化了注解收集流程的，简化了解析器和收集器的概念，由注解类自身实现自收集，对于注解元数据的使用，实际上是对一个 PHP 数组的使用，这里的简便与否就因人而异了，不过在我看来的确也还有优化的空间； swoft的Entity层是个人比较喜欢的，弱类型语言导致我们都要面相数据库工具开发，有了实体层与数据库字段的映射方便程序员开发时候不用一直去看数据库，找到实体层，实体层可以定义关联注解，类似spring，那是比较完美的，swoft缺陷没办法定义模型关联 Hyperf 使用的 ORM 是基于 Eloquent 的协程化修改版本，除了不像 Doctrine 那样通过注解定义 Entity，其余你所说的都是有的； 框架启动做的很粗糙， 没有重启 停止功能 这样的设计也是有意而为，不然从 Hyperf 1.0 到现在都迭代了一百多个版本了，PR 也接收到了好几个与此有关的，那为什么不加呢？ 在实际运行过程中，合理的做法只有两种，一是通过启动命令直接运行前台程序，这种做法一般只作用于开发阶段，因为开发阶段需要查看代码的报错信息，而 cli 和 fpm 对报错内容的显示是不一样的，fpm 下会通过浏览器输出或写入到 fpm 的日志文件中，而 cli 下，你只需要看前台程序的 stdout 内容输出即可，如果也将错误内容通过 HTTP Server 发送到浏览器的话，会导致启动阶段的报错看不到；二是通过 Supervisor 或 Docker/Kubernetes 等工具来运行一个前台程序实例（是的，这种方式需要的也是前台程序），这种做法一般作用于生产阶段，当然也可能会使用 Docker 作为开发阶段的运行环境，这里所提到的方式都是前台程序，那后台运行只会存在于一些不合理的使用方式下，故 stop 和 restart 命令也只会作用于不合理的使用方式下，不默认提供这些命令能使用户更容易以合理的方式来使用，如用户真的有需要使用后台程序运行，通过 pid 和信号命令也可很简单的实现相关功能； 没有一些内置的公共函数，有时候用起公共函数还是比较舒服的，就比如context()通过上下文直接获取一个response对象特别方便 这个也是有意不提供的，因为这种使用方式是错误的，从 Context 中取对象是一种非常奇怪的做法（当然实际上会储存对象），如果是这样的话，那用户要如何区分什么时候从 Context 获取对象，什么时候从 依赖注入容器 Container 获取对象呢？故所有的对象获取都应该是从 依赖注入容器 Container 获取，获取到的对象内部可再根据自己的需求从 Context 获取来提供代理对象（参考 StaticInstance），所以你会发现在 Hyperf 里获取 Request/Response 对象也是通过 依赖注入容器 Container 来获取的，框架会自动区分不同协程下的对象区分； 那关于公共函数又会导致什么问题呢？不会导致什么问题，提供更多的 Function 非常的简单，但会让代码的可替代性变差，所以控制 Function 的数量是一件很难的事情，Hyperf 的关于组件设计理念是 可替换 与 可复用 的，那如果类实现和方法调用都是基于依赖注入来实现的话，再配合 AOP，这一切都能完美的实现，通过 Function 来实现方法调用的话，Function 的内容是无法被替换和重写的，因为在 PHP 中没有办法实现对一个 Function 方法的重载，故减少或不使用 Function 是一种更合理的做法； — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[littlecxm]

命令行放在 /bin/hyperf.php 也是有意为之的嘛？比如laravel都是放在根目录直接php artisan 了

[limingxinleo]

是的，不想放根目录，如果有人定制启动文件，正好可以放到一个目录里

[huangzhhui]

补充一下，.php 也是有意保留的，目的是不想隐藏这是一个 php 脚本的事实，比如 php artisan 这样的命令会让你感觉到 artisan 这个脚本是不可编辑不可更改的，但如果保留 .php 的话，使用者就很清楚这是一个 PHP 文件，是可以随意在启动阶段做一些想要的定制的