Laravel Web 和 API 控制器结构。分离与干燥答案

【问题标题】：Laravel Web and API controller structure. Separate vs DRYLaravel Web 和 API 控制器结构。分离与干燥
【发布时间】：2017-09-24 13:19:06
【问题描述】：

我想构建一个同时使用 Web 和 API 部分的 Laravel 应用程序。常见的（也是我的）问题是是否使用单独的控制器。

有两种选择：

独立的控制器 Laravel API controller structure?
使用一个控制器并检查请求类型（是 Ajax，或取决于请求链接）并返回 JSON 或 HTML。 Laravel resource controllers for both API and non-API use

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

我认为第二种方法没有任何缺点。但是人们会说类似

如果你只使用一个控制器，你很快就会得到一个包含数千行代码的凌乱类。这不仅不会很好地扩展，而且对你和你的队友来说也很难合作。

请解释一下第一种方法（独立控制器）的 DRY 问题解决方案以及第二种方法（单控制器）中可能出现的水下岩石

请说明哪种方法更可取。

【问题讨论】：

Repository 模式将数据访问逻辑分离并映射到业务逻辑中的业务实体。为 web 和 api 控制器创建一个通用存储库。
@sumit 如果可以的话，我会多次投票。
@sumit 无论是否使用存储库，控制器方法不都是一样的吗？退货部分除外。是的，小控件，但几乎一样？
查看bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5
@smit 我以前读过这篇文章，然后又重读了一遍。它讲述了获取数据的更高层次的抽象。但是 API 和 WEB 方法应该具有相同的外观（使用存储库获取数据）但返回语句不同。所以我看不出这对我的问题有什么帮助。即使方法由 2 行组成（如文章中所示），是否有理由在不同的控制器中重复它们以替换 retrurn 语句？

标签： laravel

【解决方案1】：

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

我可以看到这两种方法的论点。但是，我会创建和维护单独的控制器，同时使用服务在已知永远不会改变的控制器之间共享公共逻辑。

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

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

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

【讨论】：

你说> 比如你允许用户上传头像图片。我会把这样的逻辑放在一个服务中，并在两个控制器中使用这个服务。我不明白。在两个控制器中调用服务不会相同吗？像`$data = $this->userService->getAll($resourceOptions);` 这样的东西在两个控制器中不是一样的吗？请解释一下。
没错。对服务的调用可能是相同的，但可能具有不同的参数。但是，这意味着您通过不复制两个控制器中的所有逻辑来保持代码干燥。相反，它集中在服务中。
对不起，我不明白。两个控制器中应该仍然有相同的方法。它们将具有相同的服务调用部分，并且仅在返回部分（JSON 或 HTML）上有所不同。所以我们违反了 DRY。但是你说我们应该划分控制器。我误解了什么吗？也许单独控制器的关键思想是，将来这些方法需要更多的差异，然后迟早返回部分（尽管我不明白为什么）。这可以解释分离的概念。
我要么使用相同的控制器并根据请求更改响应，但为 Web 和 API 分别命名路由指向相同的控制器操作或创建完全独立的控制器重复的操作，并尽可能将逻辑整合到服务中。
这完全是我的问题 - 使用哪个或这个 EITHER/OR 以及为什么。 (-: