Laravel Web 和 API Controller 结构。分离与干燥

Question

我想构建一个同时使用 Web 和 API 部分的 Laravel 应用程序。常见的(也是我的)问题是是否使用单独的 Controller 。

有2个选项:

独立 Controller
Laravel API controller structure?

使用一个 Controller 并检查请求类型(是 Ajax，或取决于请求链接)并返回 JSON 或 HTML。
Laravel resource controllers for both API and non-API use

那些有第一意见的人没有解释 DRY 问题的解决方案 - 除了返回语句(JSON 或 HTML View )之外，Web 和 API Controller 将是相同的。但是由于大多数帖子都建议将 Controller 分开，我怀疑我对 DRY 问题解决方案一无所知。

我没有看到第二种方法的任何缺点。但人们会说类似

If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.

请向我解释第一种方法(独立 Controller )的 DRY 问题解决方案以及第二种方法(单 Controller )中可能出现的水下岩石

请解释哪种方法更可取。

Answer 1

我认为这是一个很好的问题，我也很想看到答案。

我可以看到这两种方法的论点。然而，我会创建和维护单独的 Controller ，同时使用服务在 Controller 之间共享已知的公共(public)逻辑，这将永远不会改变。

例如，如果您允许用户上传头像图像。我会把这样的逻辑放在一个服务中，并在两个 Controller 中使用这个服务。

在我看来，这种方法的原因是 Web 和 API 逻辑可能会发生分歧，因此在不影响另一个的情况下迭代它们会更容易。

如果这不太可能，那么我仍然会创建单独的路由，但将它们都指向同一个 Controller ，这样如果将来它确实发生了变化，您可以简单地将 API 路由重新指向它们自己的 Controller 。