推广比代码难多了。我自己的感觉

@jqh 问题是为什么一个简单的登录，会搞出那么多东西出来？ 真的会有人重写这个 guard 的实现么？
控制器的 $this->guard() 要查找多少代码理解。这也就是 Laravel 不能用 类名 /方法 文件路由的原因。
我刚才查了手头的 laravel 6 的 例子，没找到你这段代码，不知道你这是 laravel 几的版本。

业务层必须能用命令行运行，最好是无状态的。Web 控制器层不做业务。 控制器不能 dump 起来一堆方法都不知道干什么的。

不要指望应用工程师通读了 Illuminate\Auth 和 Illuminate\Foundation\Auth 之后才开始工作。

@jqh 这是一个例子恰好演示了其糟糕性。
单是返回就有四种可能

return $this->error($vaptcha->getError());
return $this->validationErrorsResponse($validator);
return $this->sendLoginResponse($request);
return $this->validationErrorsResponse([$this->username() => $this->getFailedLoginMessage(),]);

而且注意到的是，按常理，最后一个才是正常返回。取反放最后就是。
但是这样还没完。
validationErrorsResponse 接受的参数又是 Validator ,又是 array 。还好 php 是弱类型。
可是 $this->getFailedLoginMessage() 又从哪里来？ 是否前面的调用会影响状态。
$this->guard()->attempt($credentials, $remember)

这个 guard() 也是怎么冒出来的，为什么要和控制器耦合，这个 attepm 词也很少见。
为什么不是 this->attempt($credentials, $remember)

下面是我重构的结果。

```
class MyController
{
public function postLogin(Request $request)
{
// 输入处理，放前面，不必节省性能。
$remember = (bool) $request->input('remember', false);
$credentials = $request->only([$key_username, 'password']);
//这也算输入吧
$key_username= $this->username();

//验证码服务
$error = VaptchaService::make()->validate();
if ($error) {
// 验证不通过
return $this->error($error);
}

//兼容，如果 service 有方式获得这个 $guard，则不需要输入。
$guard = $this->guard();

//登录服务
$error = LoginService::make()->login($guard,$key_username,$credentials,$remeber);

if($error){
if(is_array($error)){
$error[$key_username] = $this->getFailedLoginMessage();
}
return $this->validationErrorsResponse($error);
}
return $this->sendLoginResponse($request);
}
}
class VaptchaService
{
// 省略 make 静态方法。
public function validate()
{
// 验证验证码是否正确
if (! Vaptcha::make()->validate()) {
return $vaptcha->getError();
}
return null;
}
}
class LoginService
{
// 省略 make 静态方法
public function login($guard,$key_username,$credentials,$remember)
{
// 验证参数
$validator = Validator::make($credentials, [
$key_username => 'required',
'password' => 'required',
]);
if ($validator->fails()) {
return $validator;
}
// 登录验证
$flag=$guard->attempt($credentials, $remember);
if (!$flag) {
return [ $key_username => "something wrong"];
}
return null;
}
}
```

如果使用 DuckPhp 你大概会这么写。

```
class MyController
{
// 登录页面
public function login()
{
C::Show([],'login');
}
//处理 post
public function do_login()
{
// 输入处理，放前面，不必节省性能。
$remember = (bool) C::POST('remember', false);
$credentials = C::SG()->_POST();

$error=null;
try{
//验证码服务
VaptchaService::G()->validate();
//登录服务,返回用户信息。
$info = LoginService::G()->login($credentials,$remeber);
//保存 session 数据
SessionService::G()->setLoginUserInfo($info);

C::Show(get_defined_vars(),'login-done');
}catch(\Throwable $ex){
$error = $ex->getMessage();
C::Show(get_defined_vars(),'login');
}
}
}
```
为什么要调 3 个服务解决问题，而不是一个，
第一个是处理验证码的，和 web 平台有关的特殊服务
第二个是主要业务，测试的时候，可以命令行运行，获得信息，不必通过 web
第三个是 session 系统管理，管控所有 session 系统，也是和 web 平台有关的特殊服务

@jqh
“应用工程师一个 DuckPhp 命名空间的东西也用不到”，你这句话翻译一下就是：这个框架基本什么基础功能都不提供。
----
是有这么一个基本用不到的功能：是你可以无缝替换成另一个框架。 翻译就是无耦合。

HTTP 请求， $_GET，$_POST 还没死绝呢。PHP 官方又没出一个自己的 psr 接口。PHP 为什么比 Java 容易明白没？
Framework 和 Library 的区别知道么。 非得所有的都要要你 framework 里的么？
没关系，核心工程师怎么偷换实现都不会乱， 反正应用工程师看不到。

PHP 代码是视图的原则？？这都 2020 年了，您还崇尚 HTML 和 PHP 混编呢？这写出来的代码能维护？大清早就灭亡了亲；
那么非 PHP 的视图模板里写 sql 你见过没。Widget 里一个超级对象你见过没。PHP 视图的原则是不做计算，只输出，而不是混编。
[Smarty 出了这么多年，PHPer 又退化到用 PHP 来写视图模板了]

orm 使得调试更麻烦了，laravel 提供了多种方式可以让 ORM 转化成 sql 调试，调试虽然麻烦了一点，但 ORM 带来的便利程度远远大于麻烦程度；
调试是重要工作。而且 orm 需要多学一层，所以又过滤了一部分懒人。

PHP 最大的好处之一就是随时改业务代码。
DuckPhp 好处之一就是你可以把你的中间件做成独立的工程独立使用。应该说是可以把独立工程变成“中间件”，之前回答里都有了，我上面没演示的是 view 和 配置，也可以 重载。
DuckPhp 好处之二就是这些东西都是显式表达的，你不会看到“哇靠，这东西从哪里冒出来的，究竟错在哪里”。

如果你把业务代码放在控制器里，那等到 10k 行控制器的时候维护起来就痛苦死了。

日志收集，登陆验证，接口权限判断这些，都是核心工程师的职责。所以他们会告诉应用工程师：继承这个控制器基类就够了。想改这些，在基类里改就是。

我水平不够，所以只能用 PHP 这种语言。现在高水平的都去用 Java ,Go 了。
所以我写的框架也只是适用于那些想用 PHP 快速开发的人。
[Laravel 是很优雅的框架，不应该使用 PHP 这种不优雅的语言，应该使用更好的语言来写。]

Laravel 默认的 auth 代码的流程我后来是弄清楚了。搞那么复杂的目的是为了有效的过滤智力低下的懒惰的 CURD 程序员。

DuckPhp 1.2.3 到 1.2.4 版本有个显著改变是之前组件都没继承基类，实现什么接口。只使用 SingletonEx trait 做可变单例。

按 MyComponent::G()->init(array $optioins, $context=null): this;
这样的约定初始化（可以想象成 ServiceProvider.

1.2.4 之后，各组件使用 MyComponent extends DuckPhp\Core\ComponentBase , ComponentBase implements ComponentInterface，这样的方式，多了一个继承，内部实现一个接口。

实际上你编写扩展，也只需要满足约束 MyComponent::G()->init(array $options, $context=null): this; 就行了，没必要 实现 ComponentInterface 的所有接口

ComponentBase 帮你过滤你只需要的 $options 选项。 拆分 init() 为 initOptions($options) initContext() 两个空方法以便于你的继承。

以上这些，只是核心工程师需要了解的。应用工程师用不到。
影响应用工程师的是少量选项，方法名又因为名称不满意，细调了，不兼容了。

核心工程师有没有会被版本升级恶心的事呢？ 有，继承系统类的时候，或许系统类的类型会调整成强类型，签名不同了。

最后，还可能会有什么问题呢？
Helper 的函数名字冲突，比如你在旧版本的 Helper 加了个函数， 升级后函数名相同，但签名不同，这也是不太可能出现的情况。

@ruoge3s 控制器的构造器就是干这样的活的，还觉得耦合严重。。。
控制器又不需要继承系统基本类，一看就明白。
给你看个耦合严重的控制器例子吧。

```
namespace App\Http\Controllers;

use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Routing\Controller as BaseController;

class Controller extends BaseController
{
use AuthorizesRequests, DispatchesJobs, ValidatesRequests;
}
```
这时候，你就的去看 BaseController 里有什么，会影响到什么。
还有 AuthorizesRequests DispatchesJobs ValidatesRequests 都有什么功能。
似乎这些不管也无所谓。

控制器基本不会复用，复用的是 service，业务逻辑层。

keep it simple stupid.

@DavidNineRoc
3. 如果一个项目没有中间件，我大概就知道这个项目怎么做登录验证的那种模块了，估计就是每个文件 include auth.php

这个问题我再说明一下，我刚才答错了。
DuckPhp 项目，推荐的是用 PHPer 最习惯的方式，在控制器基类构造函数里做权限判断。好处是你从代码看起的时候不会发懵：为什么这里会有个验证？ 这也就是 DuckPhp 尽量避免的，这玩意从哪里来。

我答成了使用第三方类 auth 类做验证了。
如 template 目录下的例子。

http://duckphp.demo.dev/full/public/u/index.php/login

对应的文件应该是 template/full/public/u/app/Controller/Main.php (暂时别吐槽为什么文件这么长了。
但是没看到 login 方法。
因为在
template/full/public/u/app/Base/App.php 的 oninit 里有这么几句。
$this->options['ext']['UserSystemDemo\Base\App'] = true;
$path = realpath($this->options['path'].'../../auth/');
$this->assignPathNamespace($path, 'UserSystemDemo');
后两句是 autoload 添加 'UserSystemDemo' 命名空间。
重点是第一句
把 template/full/public/auth 这个项目作为扩展来用于 auth.
template/full/public/auth/Base/App.php 只需要一句，就把这个独立工程可插件化了。
use AppPluginTrait;

独立运行 auth 项目的入口是
http://duckphp.demo.dev/full/public/auth.php

@DavidNineRoc

1 队列任务不是 Web 框架必备的部分，队列或者应该是单独的一个库。数据库也不是。但是作为常用组件，DuckPhp 通过默认扩展的方式提供主从数据库的支持。另一个默认扩展，就是分页了。 分页在各应用里绝对都是很折腾的方式，所以 DuckPhp 也带了基础的分页，并很容易改写。

2 文件路由，namespace 分割，如果有更特殊需求，加路由钩子。

3 路由前后钩子。中间件搞得堆栈混乱一堆。中间件还存在为调用顺序折腾的事。 如果路由钩子多起来，那么我会提供调用方式调整的方法，但是希望是手动。

4 一个社区也是由一小撮人慢慢发展起来的。并不是说 symfony 不好。为什么能推广开的是 laravel 而不是 symfony 我很奇怪。 比如 html 编码。 我提供了一个默认方式，zend framework 有更好的方式，你可以很容易的去替换成 zend framework 。symfony 的例子意思是可靠性最好不要建立在 第三方基础上，而是自己有实现，也可替换成第三方实现。

因为我闭门造车，很多小的细节不可避免的有问题，目前就是希望能有一小撮人一起来讨论，做好。

@wowiwj
laravel 的运行效率，已经有太多例子了。
laravel 的开发效率：不要指望一个智力水平只有高中的 php 新手去使用并了解其中原理。

最好拉一些实际例子列举一些自己轮子优势。
////
我 fork 了一个 yii3 demo 的分支，用 DuckPhp 1.2.3 实现的。输出和 yii3 的一模一样。

除了入口文件，其他工程文件都在同一个目录下

https://github.com/dvaknheo/yii-demo/tree/for_duckphp/app

可以看 yii3 还是 DuckPhp 更容易明白。DuckPhp 更加朴实无华，不用那么花哨就解决问题。

之前在我本机弄了 laravel 自带的 auth 的版本，发现 laravel auth 连我都没能弄清楚，怎么可能会有国内项目用他那套做验证，都是自己从头起一套更容易。 后面是卡在验证器部分了。 要在不用 laravel 框架的情况下实现和 laravel 做表现一致的验证。后面回头做 DuckPhp 的代码了就没管这个。

@HiCode 谢谢。我希望能有一小撮人搞起。在写文档的时候，总没有底气不知道别人能否看明白。DuckPhp 的精妙之处，在使用之后会明白的。但是我做得出来，说出来就一塌糊涂。DuckPhp 也有些地方，总感觉可以做得更好，但是总是缺一个人提醒一下。

@iidestiny
Laravel 不能节省运行效率和开发效率。 违背了 PHP 简洁之道。

随手举例子

+ blade 模板 违背了 PHP 代码就是视图的原则
+ 滥用 ArrayIterator foreach, 使得没法 dump
+ orm 使得调试更麻烦了
+ 退化到路由表了。有简单的文件路由不用。
+ 中间件使得调用关系复杂化。

@littleylv .php_cs 文件， 就额外几条规则。你这里说的，没用 php-cs-fixer fix 检查出来。

```
<?php
$header = <<<'EOF'
DuckPhp
From this time, you never be alone~
EOF;
$finder = PhpCsFixer\Finder::create()
->files()
->in(__DIR__.'/src')
->name('*.php')
;
return PhpCsFixer\Config::create()
->setRiskyAllowed(true)
->setRules([
'@PSR2' => true,
'header_comment' => [
'commentType' => 'PHPDoc',
'header' => $header,
'separate' => 'none',
'location' => 'after_declare_strict',
],
'declare_strict_types' => true,
'binary_operator_spaces'=>true,
])
->setFinder($finder)
->setUsingCache(false);
```

public function _DB($tag = null) 这样的方法是对应 public function DB($tag = null) 的。


用于外部回调。 下划线开始的代码，算是一种特殊风格。

public function _onException()
public function OnException() 刚注意到这应该用 _OnException 。 代码多了，有些地方没注意得过来。

欢迎大家到 Github 上提 Issue 或者在 QQ 群里讨论

@littleylv 我系统命名空间是用 DuckPhp，所以统一成 DuckPhp 。 要不，还得把命名空间全调整成 DuckPHP ?


@jqh 不是说核心工程师造轮子，是核心工程师调轮子。应用工程师一个 DuckPhp 命名空间的东西也用不到。
DuckPhp 用 phpstan 检查过规范，phpunit 单元覆盖测试 100% 。

ControllerHelper::GetExtendStaticMethodList() => 这里只是个简写， 其实直接在 MyProject\Base\Helper\ControllerHelper 里字节加就行。 这是写插件的时候的额外方法。

是有自动加自的。

现在还有纠结代码行数的 。
////
fpm 模式下，空跑上万行和 和 100 行区别大了。 而且上万行的代码，意味着核心工程师想调整写功能也不好找。


“引用的第三方组件出了 Bug”？ symfony 家社区那么多用户，有 bug 也是很快发现或很快修复。

////
有这么一个框架，引用了低版本的 symfony 组件。symfony 后来升级了。

再说了别人有 bug，你自己造的轮子也有可能有 bug 呀
////
所以现代框架就必须要有出 Bug 的时候可以不硬改系统代码，在工程里改正的方法啊。

写业务来不及写。清理测试还折腾。虽然提炼出业务层后，内部测试方便多了。
不过写 DuckPhp 框架的时候，我做了 100% 覆盖测试。
覆盖测试比单元测试有意义吧。

顺路看了一下 typecho 的代码。和 wordpress 类似，都还是在中古时期。

毕竟不是每个虚拟主机都能上 php 7.2 的。

23559 行 php 代码，要写的话也要花很长时间才能搞定。

最难看的部分是 Widget，其他还好办.

@imme90 现在的 PHP 程序员还会 es6 之前的 js 么？
我也有过，这么简单的 js，还是我来写吧，这种时候。
所以不明白老板招那些前端来干什么

当年怎么做的？ 画图切图，静态页面是一个人负责。JS，PHP 数据库是另一个人负责，甲方画个原型图。到现在包小项目也是这么来的。
现在画图的， 一个人， 切图仔切图，写 JS 。PHP 少干了活。 对了，还有产品 也过来分钱了。

画图，切图，配色， 不应该由一个人来搞定么？考核水平就是静态页面好不好看——这是艺术家 ，话说应该怎么给这些艺术家算工资？

有这么多项目需要用到 超级复杂的 js 么？ ——当然，你要是自己弄播放器，那还是单独前端吧。这活承认比写后端的难，工资多大家服。

我 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 。看上去清晰多了。

还有想吐槽的暂时记不清，就暂时到这吧。

额，我自己失误了，G() 函数确实会在业务中用到。如果为了扩展性。
XService::G()->foo 和 XModel::G()->foo 这种用法经常有。
或许实践起来会有一排，改成 static function 调用 吧，就是
XService::foo(); 和 XModel::foo();

有一种情况是 XSerivce::G 这模式省不了， 没默认载入的扩展，JsonRpcExt 切换成远过程调用。这属于高级用法了，具体在相关 ref 里

@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 模式的文件好，综合起来，这为方便牺牲效率，这可以接受。