跟风 发一个框架吧，本来不打算发的，就自己玩玩，但是发出来感觉也可以交流学习下，让大家帮忙指点看有啥还能改进的地方
地址： https://github.com/Jetea/app 有两个版本，1.x 是只有框架基本款，2.x 是应用款（除框架外引入了模板，数据库，队列啥的）
只包含了 exception, routing, middleware. 特点：现代化设计，简单，可读性高，可扩展，没啥全局作用域的变量方法
看过各种出名不出名的框架一大堆，不过好多的框架设计都过时了，目前觉得 laravel，slimphp，sf 的代码质量算不错的，然后我这个也算不错的，哈哈哈，欢迎提出意见和建议交流方便一起提高。
 |
1
akatquas Jan 31, 2019 via iPhone
其实更像是 boilerplate ？
|
 |
2
cz5424 Jan 31, 2019 via iPhone
不懂 php，支持下
|
 |
3
lidfather Jan 31, 2019 via Android
好的东西一般都是简单的，不像有人，还创造性提出个摆叶架构。
|
 |
4
via Feb 1, 2019
“没啥全局作用域的变量方法”
老哥这个$routes 变量是咋回事？ https://github.com/Jetea/app/blob/master/app/routes/web.php 这能跑起来吗？ |
 |
5
1762628386 Feb 1, 2019
@via 我猜测的话应该是匿名函数内 include 的方式实现的，也就是说这个变量只存在这个匿名函数空间内
|
 |
7
xiaotuzi Feb 1, 2019 via iPhone
封装的不够好，比如模板渲染，控制器继承，要写好长一段…可以简单点
至于设计，因人而异了，你觉得特殊的好那就用特殊的，我觉得简单易懂易用才是方向。 |
 |
8
conn4575 Feb 1, 2019 via Android
java 里面默认都用 spring，大家共同在这个框架上完善它，然后推动整个生态的进步，php 一直在发明框架，永远不懂 java 真正强大的地方，作为曾经写过 phper，真是怒其不争啊
|
 |
9
terrywater Feb 1, 2019
Yii2
|
 |
10
theswow OP  1
@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 |
 |
11
ericgui Feb 1, 2019
这个其实是写着玩的，另外就是开源的框架中我喜欢 laravel 的代码，但是不喜欢 laravel 那种包都是依赖他自身生态的，我更喜欢 sf 框架那种组件化，每个包尽量少的依赖那种，所以会看到 sf 的包被大量的其他框架所引用，另外就是 lara 的代码写的比较绕
所以我就结合 n 多框架的实现，其中大量参考 laravel 的实现，简化提高可读性，另外就是减少依赖，当练手。 ----你这个技术观点和我不谋而合呀 我不喜欢目前的任何一种框架，我认为他们都多多少少有没想明白的地方 既然 PSR-4 规定了 namespace，那就可以把这些 component 组装起来，成为一个新的 MVC 框架 已经在 issue 里回复您了 |
|
13
theswow OP 刚看到 https://github.com/laravel/framework/pull/26898 Laravel 也要开始移除全局方法了
很多的框架都有各种全局的变量，常量(define)，函数，没在命名空间下定义，虽然有 function_exists 来判断后定义，但是会带来的问题是增加了开发人员的心理负担，比如定义了同名的，但是作用不同，那可能改变了很多。 框架作为底层，要减少应用开发人员的使用成本，减少黑魔法也很重要，也方便开发人员统一书写，比如 laravel 中很多时候，一个团队对一个请求参数的获取有好几种写法，我觉得这些地方就增加维护成本，虽然见多了就知道了，但是搜索替换的时候~ |
Select Language