Laravel 每个控制器都需要写个路由，蛋疼

[iloveyou]

用过 ci 、 yii ，都有默认的路由，基本上都是 module-controller-action ，思路走到哪，代码写到哪，非常流畅。文件组织的过程顺便把 seo 考虑进去了，只有特殊的 seo 需求才会专门订制路由。

如果每个 controller 都需要建个 route 那 controller 还有啥存在意义，都用闭包解决算了，或者路由里直接调 business 逻辑。

当然这样设计必然有其优越之处，不过编码也要考虑“爽脆度”，写起来不爽，用起来不干脆，我是适应不了。

[msg7086]

@lygmqkl 你说的都没错。
我对我自己说的话负责任，但是没法对别人因为我说的话产生的影响而负责任。
毕竟这里是讨论区，我觉得有互相不同的观点才是正常的。
那么我们就来看看你提到的这几点吧。
1. 文档，质量控制，版本控制，测试。
是的，是应该有这些。但是偏偏我司的系统就是没有。
去年来了个新员工， Ruby 老手，进来以后花了几个月时间分析和优化系统。
后来在各种注释里留下不少对之前员工的脏话后愤而辞职了。
如果你的系统这几点都能做好，当然不成问题。
但是不是所有的公司都能做到这样。就说自动路由，你能保证你对外暴露的接口都能完整地整理在文档里吗？
俗话说得好，代码才是最好的注释。显式申明你用到的路由本身就是一个精确反映实际的文档。
2. 路由在项目初期就定下来。
你开玩笑的吧，一个要做几年的项目的路由能一开始就定下来？
我们现在的系统就是 50k 行代码，前后写了七八年，经手的程序员几十人。
路由就是我 26 楼写的自动路由，前端界面往后端调用的时候直接 Call 到 Controller 上的方法。
（实际情况其实比这个还复杂点，但是和本题无关所以就不提了。如果想知道我可以再说下去。）
然而我们根本不知道前端到底用到了哪些后端方法。
所以每次动控制器的时候根本不知道哪些方法是前端会用到的，哪些是可以随便改动的。
3. 大项目拆分。
这个没错。但是有几个问题。
大项目不可能无限分割成微型项目。所以不可避免的有些项目还是有数千甚至上万行。
如果全部用自动路由，你还是得到处搜索函数名，确保没有奇怪的地方调用到你的函数，才可以改动结构。
除非你把所有的代码都从控制器里剥离出去，放在 Service 或者 Model 里。
然而这样的话控制器就成了实质性的路由文档了。
（并没什么不可以，如果架构师和程序员都靠谱的话，这样其实是不错的。）
（但是你并不总是能遇到靠谱的同事。）
4. 不知道你说的是什么。 26 楼的话，那个就是自动路由了。

最后说下利益相关吧。 PHP 从初中开始玩，那时候还只有 PHP4.x ，还没到谈框架的年代。后来 PHP5 了自己写了个框架，工作以后送给公司用了，后来成了公司的核心框架，虽然并没什么亮点。现在写 Rails ，在一个五六人的团队里一起做一个 8 年多的 Rails 1.x 项目，大概有 50k 行的量，虽然基本都是辣鸡。现代 PHP 我已经不会写了，弃掉 PHP 的时候 Composer 才刚刚出来，所以对 Laravel 了解不多，不确定显式路由是不是有坑，不过至少 Rails 里显式路由的规则数量我还是可以接受的。上文大多以 Rails 的角度来谈路由，如果 Laravel 有不同之处还请提出来。
谢谢。

[lygmqkl]

@msg7086 既然你没在写 php 那就没啥好说的了，可能我们所处的团队和理念差别较大，国内有很多夸夸其谈的人，代码不怎么样，但是说起来一套一套的，到实际项目就蔫了。

可能给你了不太好的感觉，抱歉。

[lygmqkl]

@ango 我和你的想法差不多，我思量了一下，国内还是在前期规划性稍微投入的少了一些导致的， 前期架构 SEO 这些东西都设置好，后面慢慢变。。。。。真的想想都要抓狂。

[msg7086]

@lygmqkl 很多时候的很多做法其实是妥协的结果。
如果什么事情都能找到最理想的员工用最理想的办法去做，当然什么都好说。
但是团队就是团队，就会遇上一些奇妙的事情。
比如因为没钱所以招不了大牛，因为要抢占市场所以赶着开发，遇上留下了各种技术债什么的。
自动路由大概就是技术债的一种吧。
还债方法要么用显式路由，要么就如你说的，合理拆分，详细归档。
PS: 国内情况我也不清楚，不过哪里都有你说的这种人，应该也不限定于国内的。

[msg7086]

@msg7086 s/遇上 /于是 /

[raywill]

也可以不这么玩。 Laravel 并没有要求你一定这么做，只不过大家都按照官方的建议逐步形成了这一 best Practice 而已。

不按照官方的玩法，怎么做呢？理论上可以这么做：

route.php 里面只写一个路由：
```
Route::any('/', function() {
// 自己写一段解析 queryString 的代码，然后根据参数调用对应的 Controller
});
```

不过，你就损失了 router middleware ， group routing 等等好处。一切自己动手。


更进一步地，你还可以自己重写 Routing 接口，完整实现自己的一套 Routing 方法。

[wyan453351466]

@msg7086 抱歉不能同意你的说法。“程序写了几万行以后特么根本不知道自己的程序对外暴露了多少接口出去”。问题是就算你手动路由，当路由配置写了几千行的时候 你特么也没法判断自己对外暴露了多少接口啊！！ 几千行的配置！你怎么看！更乱好吗？！

还不如自动路由，遍历一下所有控制器的方法就知道有多少接口了啊！你不想暴露的接口可以单独写在一个模块里啊！

[baoguok]

框架应该支持自动路由和显式自定义路由，这样更灵活。

我司目前使用的是自动路由，暂时没有发现什么坑，功能页面 200 个以上。

此外，管理系统和接口对路由的要求不一样。管理系统那么自动路由就非常爽，但是 api 接口那么就需要显式自定义路由+自动路由。

[elvba]

@wyan453351466
`php artisan route:list` 就能看到注册了哪些路由了
也可以用 `Route::getRoutes()` 拿到所有路由信息，然后你想怎么展示就怎么展示

[wyan453351466]

@elvba 嗯，感谢你的回复。我的意思是。为什么不能两者兼有呢？换句话说，为什么 laravel 不鼓励隐式路由的使用？

毕竟对于我来说，就算用显式路由，我也是按照一个统一的规则（模块 /控制器 /方法），重复的去写啊。。 那为嘛不直接给我自动匹配了。

刚才我反驳 @msg7086 所说的，隐式路由会导致不知道暴露了多少接口出去。我相信也可以匹配出来的啊。实现难度可能比匹配显式路由更低。

[msg7086]

@wyan453351466 看了一眼发帖时间。

显式路由是你从外部用到某个控制器方法的时候才手动加入，而隐式路由那是阿猫阿狗看到有这个控制器方法就直接怼进前端里了。

你说的这些我们都懂， Rails 也有 resources 方法可以自动生成 restful 的标准路由，一行代码解决一个 model ，如果你完全遵照统一规则来写的话，直接用 resources 就能解决了，不需要一个路由一行的。
问题是大多数时候，都是辣鸡程序员开坑，倒霉程序员跳坑，这种时候显式比隐式带来的麻烦少得多。

[elvba]

@wyan453351466
显示路由的最大好处是自由灵活，不受限制
隐式路由你需要去看文档或者看源码才知道它的匹配规则是怎样的，显示则不用
举个例子：两个不同的路由，调用同一个控制器里的方法 A ，如果是隐式路由就要再多写一个方法 B ，然后这个方法 B 再去调用方法 A ，显示路由增加一条路由规则即可，不会涉及到控制器的修改。这种场景可能不多，但肯定会有。

[nextvay]

https://blog.csdn.net/nextvary/article/details/82346940
30 行代码,解决此问题

[shanghai1998]

//from files or db,建议后台使用
$routes = [
['path'=>'/java', 'controller'=>'MovieController']
];
foreach($routes as $router) {
Route::resource($router['path'],$router['controller']);
}

//建议前台 /api 使用
Route::any('/{dir}/{module}/{action}', function ($dir, $module, $action,Router $router) {
return app()->call('App\\'.ucfirst($dir).'\\Controllers\\' . ucfirst($module) . 'Controller' .'@'.$action);
});

看看香不香